概念
「 台 帳(Ledger)」
「 取 引(Transaction)」
「 取 り 決 め(Contract)」
↓
母国語でコレらのことを定義に加える
↓
内部設計では実装のための定義が必要
↓
内部設計スタート
具体的なブロックチェーン実装の技術要素
「分散台帳」
「暗号化」
「コンセンサス」
「スマートコントラクト」
コレらを内部設計書に定義する。
ちなみに、合理的なラショナルシリーズを使うとIBMから発売される「勝てるソフトウェア」に基づくソフトウェアが完成することになる。
UMLを使うのか、使わないのか、いろいろ選ぶこともできる。
「 台 帳(Ledger)」
「 取 引(Transaction)」
「 取 り 決 め(Contract)」
↓
「分散台帳」
「暗号化」
「コンセンサス」
「スマートコントラクト」
↓
↓
プログラム指示書などへ記載
このとき、内部設計用のデザインパターン（シングルトンとかいろいろある）をできる限り使って設計を表す。
ここまでを簡単にまとめると、
「 台 帳(Ledger)」
「 取 引(Transaction)」
「 取 り 決 め(Contract)」
Contractクラスの中のインスタンスの１つにTransactionクラス型の変数を作って、Transaction型の変数はContractクラスのインスタンスメソッドのうちの１つ、ロールというかルールというか、取引を支配するルールを表す定義を表す定義を読み込んでチェックするメソッド、コレを通過したデータ（ハッシュ関数
知っていて、クリエイトされるとハッシュ関数が初期化され、取引データをputされるとハッシュ関数が実行されるマップ型のインスタンスにputされている取引データ）は通過したメソッドからセットされた「合意フラグ」なりを見て自らチェック合格という判定をできるように実装されている、と。
この取引データをブロックと呼ぶ。
このブロックを台帳クラスのインスタンスに渡す。マップ型の取引データの合意済みチェックメソッドを台帳クラスのインスタンスが呼び出して実行、合意済みなら自分（台帳クラス）を生成したTransactionクラス内では合意は取れている、と判定して次の処理である取引データを自分がアクセスできるデータベースへ永続化する処理を実行する、と。
コレが概念ベースでのハナシやね。
次は実装を睨んでのハナシになるやね。
「分散台帳」
「暗号化」
「コンセンサス」
「スマートコントラクト」
の親クラスを発見して設計するのである。
たとえば、台帳のサブクラスは分散台帳クラス、と定義するとかである。内部設計やね。
本当にサブクラスで良いのか？ は検討しないとならない。概念ではブロック内にあるべき。だから台帳は分散台帳であるべき、とか簡単に考えないのである。共有だからナー と考えて分散台帳には取引データがあってもよいけどアクセスできる参加者は1人だけ・・・というプロジェクトなら・・・だよナー とか考えてプライベートスコープ、返すのは参照だけ・・・でいいなら、だが・・・のアクセサー、と。
分散台帳は台帳のサブクラスだ、というなら基本設計までならハナシとしてはOK。分散台帳は共有可能で参加者なら誰でも参照できるが、取引データを記録する資格や取引データに合意する機能を実行できる人は？ と考える。ふつうは、だが。
こうして分散台帳クラスのインスタンスは、台帳クラスがあってもなくても良さそうだナー と思うようになるであろう、と私はみている。台帳の機能を設けたいなら別だが。
ソレならソレ、拡張して分散台帳
ソレなら分散台帳はブロックの中だけ？ ソレとも外にもある？ と。ブロックへの合意は意味に応じて（正しく合意されてきたかをチェックするなら初めの方で、このブロックでの合意をするなら最後の方で、とか）何度か呼ぶようにする、と。取引データが正しいようなら永続化して合意・・・。その後で通信用のビーンに詰め替えて次のブロックへ、で良いならそのようにする、と。
こうして、最後まできたらブロックの合意数をブロックの内部の分散台帳クラスのインスタンスに数えさせて正しい数なら最終合意に向けて最後のブロック総当たりチェックをするのである。たぶん、だが。コレでデータベースに永続化された取引データをもう一回チェックする目的ではないのだが、整合性をチェックしたいだけなのだが、すべての段階で正しいデータであったのであればすべてのブロックを信用することにして、次に信用したブロック数と合意数をそれぞれ正しくカウントして、数値が合致したら取引成立を合意する、送金処理スタート、着金待ち、着金、と。それ以降の銀行取引もそれ以降にちゃんと行い、資産と対価の交換が完成。コレで1取引終了。
サイバー攻撃があったら？
攻撃者は証拠を消して取引を盗みとるのてある。
そこで、誰も信じないチェックメソッドがブロックの内部に実装されることが重要、と。
ブロックはサイバー攻撃によって破壊されていないかもしれない、証拠が無いなら無いで取引データは記録する。破壊されていなくても破壊されたら瑕疵になるような破壊痕があれば、その取引は即座に終わり、または即座にエラー処理実行、と。
眠くなったのでコレでこの記事の使命は終える。