add mention of reserve feature and description of async of ABCI

docs/en/03-tx-sharing.md

@@ -6,9 +6,9 @@ A client can send a transaction to any of the Ostracon nodes that joining the bl
 
 ## Mempool
 
-Once a block is accepted by the Ostracon consensus mechanism, the transactions contained in that block are considered *confirmed*.  The Ostracon node that receives an unconfirmed transaction validates it such as signature verification and stores it in an area called **mempool**, which is separate from the blocks.
+Once a block is accepted by the Ostracon consensus mechanism, the transactions contained in that block are considered *confirmed*. The unconfirmed transactions are validated stored in an area called **mempool**, which is separate from the block storage, after validation such as signatures.
 
-Unconfirmed transactions stored in the mempool by one Ostracon node are broadcast to other Ostracon nodes.
+Unconfirmed transactions stored in the mempool by an Ostracon node are broadcast to other Ostracon nodes.
 However, if the transaction has already been received or is invalid, it's neither saved nor broadcast, but discarded.
 Such a method is called *gossipping* (or flooding) and a transaction will reach all nodes at a rate of $O(\log N)$ hops,
 where $N$ is the number of nodes in the Ostracon network.
@@ -20,16 +20,18 @@ The following figure shows the flow of an Ostracon node from receiving an unconf
 
 ## Performance and Asynchronization
 
-Blockchain performance tends to focus on the speed of block generation, but in a practical blockchain system, the efficiency of sharing transactions among nodes is also an important factor that significantly affects overall performance.
+Blockchain performance tends to focus on the speed of block generation, but in a practical system, the efficiency of sharing transactions among nodes is also an important factor that significantly affects overall performance.
 In particular, Ostarcon's mempool must process a large number of transactions in a short period in exchange for Gossipping's network propagation speed.
 
 Ostracon has added several queues to the Tendermint implementation for the mempool to make them asynchronous.
-This improvement allows large numbers of transactions to be stored in the mempool in a short period of time, improving the throughput of the blockchain network in more modern CPU core-equipped node environments.
+This change allows large numbers of transactions to be stored in the mempool in a short period of time, improving the throughput of the blockchain network in more modern CPU core-equipped node environments.
+
+With this asynchronization of the mempool, multiple transactions will have a *validation-processing* state at the same time; Ostracon will refuse to receive transactions when the mempool capacity is exceeded, but asynchronous validation-processing transactions are also correctly included in the calculation of this capacity limit.
 
 ## Tx Validation via ABCI
 
 ABCI (Application Blockchain Interface) is a specification for applications to communicate with Ostracon and other tools remotely (via gRPC, ABCI-Socket) or in-process (via in-process).
 For more information, see [Tendermint repository](https://github.com/tendermint/tendermint/tree/main/abci).
 
-Ostracon's unconfirmed transaction validation process also queries the application layer via ABCI.
-This behavior allows the application to avoid including (correct from a data point of view but) essentially unnecessary transactions in the block.
+The process of validating unconfirmed transactions also queries the application layer via ABCI. This behavior allows the application to avoid including transactions in the block that are essentially unnecessary (although correct from a data point of view). Here, Ostracon replaces the Tendermint implementation with an asynchronous API that can start the validation process for the next transaction without waiting for ABCI-side validation results. This improvement improves performance in environments where applications are allocated separate CPU cores.
+

docs/ja/03-tx-sharing.md

@@ -2,39 +2,28 @@
 title: Transaction Sharing
 ---
 
-クライアントはブロックチェーンネットワークを構成している Ostracon ノードのいずれかにトランザクションを送信することができます。トランザクションは
-他の Ostracon ノードに伝搬し最終的にすべての Ostracon ノードで共有されます。
+クライアントはブロックチェーンネットワークを構成している Ostracon ノードのいずれかにトランザクションを送信することができます。トランザクションは他の Ostracon ノードに伝搬し最終的にすべての Ostracon ノードで共有されます。
 
 ## Mempool
 
-あるブロックが Ostracon のコンセンサス機構によって受理されたとき、そのブロックに含まれているトランザクションは *確定した* とみなされます。
-未確定のトランザクションを受信した Ostracon ノードは署名などの検証を行ってブロックとは別の **mempool** という領域に保存します。
+あるブロックが Ostracon のコンセンサス機構によって受理されたとき、そのブロックに含まれているトランザクションは *確定した* とみなされます。未確定のトランザクションは署名などの検証を経てブロックストレージとは別の **mempool** という領域に保存されます。
 
-ある Ostracon ノードが mempool に保存した未確定のトランザクションは他の Ostracon ノードにもブロードキャストされます。ただし、既に受信済み
-であったり不正なトランザクションの場合には保存やブロードキャストは行われずに破棄されます。このような手法は *gossipping* (または flooding)
-と呼ばれ、$N$ は Ostracon ネットワークのノード数として $O(\log N)$ ホップの速度ですべてのノードに到達します。
+また特定の Ostracon ノードが mempool に保存した未確定のトランザクションは他の Ostracon ノードにもブロードキャストされます。ただし、既に受信済みであったり不正なトランザクションの場合には保存やブロードキャストは行われずに破棄されます。このような手法は *gossipping* (または flooding) と呼ばれ、 $N$ を Ostracon ネットワークのノード数として $O(\log N)$ ホップの速度ですべてのノードに到達します。
 
-[リーダー選出](02-consensus.md)によって Proposer に選ばれた Ostracon ノードは mempool に保存されているトランザクションから
-新しい提案ブロックを生成します。以下の図は Ostracon ノードがトランザクションを受信し mempool に保存してブロック生成に使用されるまでの
-流れを示しています。
+[リーダー選出](02-consensus.md)によって Proposer に選ばれた Ostracon ノードは mempool に保存されているトランザクションから新しい提案ブロックを生成します。以下の図は Ostracon ノードがトランザクションを受信し mempool に保存してブロック生成に使用されるまでの流れを示しています。
 
 ![Mempool in Ostracon structure](../static/tx-sharing/mempool.png)
 
 ## Performance and Asynchronization
 
-ブロックチェーンの性能はブロックの生成速度が注目されがちですが、現実的なブロックチェーンシステムではノード間のトランザクション共有効率も全体の
-性能に大きく影響する要因です。特に Ostarcon の mempool はネットワーク浸透速度の速い gossipping を使用している対価に短時間で大量の
-トランザクションを処理する必要があります。
+ブロックチェーンの性能はブロックの生成速度が注目されがちですが、現実的なシステムではノード間のトランザクション共有効率も全体の性能に大きく影響する要因です。特に Ostracon の mempool はネットワーク浸透速度の速い gossipping を使用している対価に短時間で大量のトランザクションを処理する必要があります。
 
-Ostracon は mempool に関して Tendermint の実装にいくつかのキューを追加して非同期化を行っています。この改善によって短時間に大量のトランザクションを
-mempool に格納することができるようになり、より現代的な CPU コア数を搭載するノード環境でブロックチェーンネットワークのスループットを改善して
-います。
+Ostracon は Tendermint の mempool 実装に対していくつかのキューを追加することでトランザクション検証処理の非同期化を行っています。この変更によって短時間に大量のトランザクションを mempool に格納することができるようになり、より現代的な CPU コア数を搭載するノードでのネットワークのスループットの限界を改善しています。
+
+この mempool の非同期化に伴って同時に複数のトランザクションが*検証中*の状態を持つようになります。Ostracon は mempool の容量を超過するとトランザクションの受信を拒否しますが、非同期で検証中のトランザクションもこの容量制限の算出に正しく含まれます。
 
 ## Tx Validation via ABCI
 
-ABCI (Application Blockchain Interface) はアプリケーションが Ostracon やその他のツールとリモート (gRPC, ABCI-Socket 経由) または
-プロセス内 (in-process 経由) で通信するための仕様です。ABCI の詳細については [Tendermint のリポジトリ](https://github.com/tendermint/tendermint/tree/main/abci)
-を参照してください。
+ABCI (Application Blockchain Interface) はアプリケーションが Ostracon やその他のツールとリモート (gRPC, ABCI-Socket 経由) またはプロセス内 (in-process 経由) で通信するための仕様です。ABCI の詳細については[Tendermint のリポジトリ](https://github.com/tendermint/tendermint/tree/main/abci)を参照してください。
 
-Ostracon のトランザクション検証過程では ABCI を経由してアプリケーションレイヤーにも問い合わせを行います。この動作により (データの観点では正しいが)
-本質的に不要なトランザクションをブロックに含めないようにアプリケーションが判断することができます。
+未確定トランザクションの検証過程では ABCI を経由してアプリケーションレイヤーにも問い合わせを行います。この動作により (データの観点では正しいが) 本質的に不要なトランザクションをブロックに含めないようにアプリケーションが判断することができます。ここで Ostracon は Tendermint 実装を非同期API に置き換えることによって ABCI 側の検証結果を待つことなく次のトランザクションの検証処理を開始できるようになりました。この変更は別のサーバで動作するアプリケーションや、個別の CPU コアが割り当てられているアプリケーション環境でのパフォーマンスを向上させます。