Improve documentation.

README.md

@@ -19,76 +19,89 @@ Smart Transaction のプログラムは WebAssembly 等にコンパイルされ
 Smart Transaction が実行されると、結果的にブロックチェーンを更新する Aggregate Transaction が生成されます。
 
 Smart Transaction のコードは Metal によってブロックチェーン上に固定されており不変なので、
-入力データが同じなら出力も同じになることが期待できます。
+入力データが同じなら出力も同じになる事を期待できます。
 
-Smart Transaction は基本的に、サービスプロバイダー側がデプロイするものであり、
+基本的に Smart Transaction はサービスプロバイダーがデプロイするものであり、
 顧客が Smart Transaction を実行して「申し込む」図式になります。
-従って、サービスプロバイダーは「突然、悪意のある Smart Transaction を送りつけられ署名させられる」事はありません。
+従って、サービスプロバイダーが「突然、悪意のある Smart Transaction を送りつけられ署名させられる」事はありません。
 つまり、Smart Transaction は、同じマルチシグトランザクション手法である Aggregate Bonded Transaction と比べても、 
 多くの点でセキュリティアドバンテージを持ちます。
 
 **もう Aggregate Bonded Transaction は不要です！**
 
-> 何となく「Smart Contract」と似たような雰囲気ですが、Smart Transaction あくまでも他者間の合意形成（の手助け）が基本機能になります。
-> Smart Transaction には Smart Contract の様な自律機能がありません。
-> Smart Transaction の実行結果をブロックチェーンに反映するには、必ず取引関係者の承認（署名）が必要になります。
+> #### 「スマートコントラクト」との違い
+> 
+> 何となく「スマートコントラクト」と似たような雰囲気ですが、
+> あくまでも Smart Transaction は多者間の合意形成（の手助け）が基本機能になります。
+> 
+> スマートコントラクトの様な自律性が Smart Transaction にはありません。
+> Smart Transaction の実行結果をブロックチェーンに反映する為には、必ず関係者の承認（署名）が必要になります。
+> 
+> また、スマートコントラクトの様な「コントラクトからのみ書き換え可能なストレージ」は存在せず、
+> Smart Transaction のプロトコル外から書き換えられる可能性があることに留意してください。
 
 ### 1.2. Smart Transaction の動作原理
 
 ![Diagram](./medias/smart_transaction_diagram.png)
 
 #### サービスの準備
 
-1. サービスプロバイダーが Smart Transaction を準備し、コンパイルし、Metal 化してブロックチェーンにデプロイします。
+1. サービスプロバイダーが Smart Transaction を準備し、コンパイルし、Metal に Forge してブロックチェーンにデプロイします。※①
 2. Smart Transaction の Metal ID と、仕様（関数名や引数の仕様）を公開します。
+   通常は立派な UI が付いて Web やスマホアプリとして公開されるでしょう。
 
 #### 取引の開始
 
-1. 顧客が Smart Transaction を自身の環境で実行し Aggregate Transaction を生成します。※①②
-2. Aggregate Transaction へ顧客自身のプライベートキーで署名し「トランザクションハッシュ」と「シグネチャー」を取得します
-   （トランザクション本体は不要なので捨てます）※③
-3. これらハッシュとシグネチャー、及び Smart Transaction のMetal ID・関数名・引数リスト（以降 Call Data と呼ぶ）を適切にエンコードして、
-   新たに作ったサービスプロバイダー向けの転送トランザクション（のメッセージ）にセットしアナウンスします。<br /> 
-   この転送トランザクションを「Call Transaction」と呼びます。※④
-4. 顧客は、サービスプロバイダーによって求める Aggregate Transaction が実行されるのを待ちます。
+1. 顧客が自身の環境で Smart Transaction を実行し Aggregate Transaction を生成します。※②③
+2. 顧客自身のプライベートキーで Aggregate Transaction へ署名し「トランザクションハッシュ」と「シグネチャー」を取得します
+   （トランザクション本体は不要なので捨てます）※④
+3. 上で得られたトランザクションハッシュとシグネチャー、及び Smart Transaction のMetal ID・関数名・引数リスト
+   （以降 Call Data と呼ぶ）を適切にエンコードして、
+   新たに作ったサービスプロバイダー向けの転送トランザクション（のメッセージ） に添付しアナウンスします。<br /> 
+   この転送トランザクションを「Call Transaction」と呼びます。※⑤
+4. 顧客は、求める Aggregate Transaction がサービスプロバイダーによって実行されるのを待ちます。
 
 #### サービスの提供
 
 1. Call Transaction を受け取ったサービスプロバイダーは、まず Call Transaction のメッセージをデコードして正当なものか検証します。
-2. 次に Call Data を入力として、同じ Smart Transaction を実行し、出力された Aggregate Transaction に「連署」してアナウンスします。
-   尚、トランザクションハッシュや顧客のシグネチャー等、必要な情報は Call Transaction に添付されています。※⑤⑥⑦
+2. 次に、Call Data を入力として顧客と同じ Smart Transaction を実行し、出力された Aggregate Transaction に「連署」してアナウンスします。
+   尚、トランザクションハッシュや顧客のシグネチャー等の必要な情報は Call Transaction に添付されています。※⑥⑦⑧
 3. Smart Transaction の実行結果と顧客・サービスプロバイダー双方のシグネチャーが正しければ、ブロックチェーン上でトランザクションが承認され、   
-   取引が成立します。万が一、シグネチャーが不正であったならばネットワークがトランザクションを否認するので、
+   取引が成立します。万が一、トランザクションの内容またはシグネチャーのどちらかが不正であったならば、ネットワークがトランザクションを否認するので、
    Smart Transaction の結果をサービスプロバイダーが検証する必要はありません。
 
-> 更なる連署が必要なトランザクションでは、関係人物全員が一様に Smart Transaction を実行し連署する事になるでしょう。
+> 更なる連署が必要な、三者以上のマルチシグトランザクションでは、
+> 関係者全員が一様に Smart Transaction を実行し連署する事になるでしょう。
+> 
+> 本実証コードでは二者のマルチシグのみ実装しています。
 
 ### 1.3. Smart Transaction の利点
 
-Symbol で多者間のマルチシグトランザクションを実行する場合、
+Symbol ブロックチェーンで多者間のマルチシグトランザクションを実行する場合、
 Aggregate Transaction は（特に Aggregate Bonded Transaction では）、
 セキュリティ上、必ず署名する前にトランザクションの内容を精査する必要があります。
 
-これには「取引を持ち掛ける側がトランザクションの内容を自由に組み立てる」点に脆弱性があるためです。
-さもなければ、悪意のあるトランザクションに署名させられ資産を失う危険性があります。
-事実、本脆弱性を利用した所謂「アグボン詐欺」の被害が拡大した過去もあります。
+これは「取引を持ち掛ける側がトランザクションの内容を自由に組み立てる」という点に脆弱性があるためです。
 
-この脆弱性を対策するには、
+さもなければ、悪意のあるトランザクションに署名させられ、資産を失う危険性があります。
+事実、過去にこの脆弱性を利用した、所謂「アグボン詐欺」の被害が拡大しました。
+
+この脆弱性への対策では、
 
 1. トランザクション送信元を信頼できるものに絞る
 2. トランザクションの内容を逐一検証する
 
 という手順が必要です。
 
 つまり、これらを対策した上で、
-更に Aggregate Bonded Transaction の「10 XYM のハッシュロックが必要」というネガを取り去ったのが Smart Transaction です。
+ついでに Aggregate Bonded Transaction の「10 XYM のハッシュロックが必要」というネガを取り去ったのが Smart Transaction です。
 
-Smart Transaction ではブロックチェーンに固定されたコードがトランザクションを生成することで、
+Smart Transaction では、ブロックチェーンに固定されたコードがトランザクションを生成することで、
 悪意のあるトランザクションが入り込む可能性を排除します。
-サービスプロバイダーは、単に Smart Transaction を使ってトランザクションを生成し連署してアナウンスするだけで、
+サービスプロバイダーは、単に同じ Smart Transaction を実行してトランザクションを生成し連署してアナウンスするだけで、
 安全にサービスを提供できるというわけです。
 
-連署の自動化も容易でしょう。
+**連署の自動化も容易でしょう。**
 
 もう一度言います。**もう Aggregate Bonded Transaction は要りません！**
 
@@ -98,11 +111,12 @@ Smart Transaction ではブロックチェーンに固定されたコードが
 
 実証コードでは簡単なモザイク販売を行うだけの Smart Transaction を実装しています。
 
-コマンドラインで実行する Node.js プログラムで実装しています。
+また、Smart Transaction を起動するプログラム本体は、Node.js コマンドラインプログラムで実装しています。
+従って実行にはまず [Node.js](https://nodejs.org/ja/) のインストールが必要です。
 
 ### 2.1. ビルド
 
-> この説明では Node の環境がインストール済みである前提です。
+> 以降の解説では Node.js 環境がインストール済みである前提です。
 
 #### 1) Rust 開発環境のインストール
 
@@ -273,7 +287,7 @@ export interface CallTransactionPayload {
 ```
 
 Smart Transaction が生成するトランザクションの内容に加えて `deadline` と `max_fee`、`signer_public_key` が同じであれば、
-ハッシュ・シグネチャも同一になります（本プロトコルのキーポイント）
+ハッシュ・シグネチャーも同一になります（本プロトコルのキーポイント）
 
 `method_name` でメソッドが指定できるように見えますが、それは将来的な想定であって、今のところ `exchange` 固定です。
 
@@ -339,16 +353,19 @@ Call Transaction が来たらデコードしてメッセージ JSON の型を検
 
 ## 4. 課題と今後
 
-実証コードでは課題は多く、実用まではまだまだといったところです。
+実証コードでは課題が多く、まだまだ実用まで掛かりそう、といったところです。
+
+完成までは
 
-- WebAssembly ランタイム（現 SmartTransactionService）の整備、Symbol ライブラリの整備、セキュリティ検証
+- 三者以上のマルチシグ対応
+- WebAssembly ランタイム（現 SmartTransactionService）の整備、Symbol ライブラリの整備、セキュリティ検証。
 - Smart Transaction 開発環境の整備。恐らく wasm-bindgen と似たような専用の処理系が必要でしょう。
 - ドキュメントの整備
 - 対応ウォレットの開発
 - Etherscan の様な Smart Transaction のインスペクションサイト
 
 等などが必要かと思います。
 
-何か質問等ありましたら Discussion へ、不具合等は Issue へお寄せいただければと思います。
+以上、何か質問等ありましたら Discussion へ、不具合等は Issue へお寄せいただければと思います。
 
-尚、本リポジトリは MIT ライセンスといたします。
+本リポジトリは MIT ライセンスといたします。