は、はい！（汗）

承認技術とは、XRPレジャーに限らずあらゆる分散型台帳プラットフォームに実装されている機能となっております。

下記で承認技術とはどういうものなのか具体的に見ていきましょう！

二重支払い問題とは、インターネット上で何らかの価値の交換をする際に浮き彫りとなる課題です。

この課題を初めて非中央集権的な形で解決をしたのがビットコインのPoW承認技術とされています。

二重支払い問題とは、ある任意の単位の価値を、本来であれば一つの主体にしか送信できないにも関わらず、複数の主体に送信ができてしまうという課題です（価値の複製）。

本来、金融機関などは、中央集権的な形で二重支払い問題を解決してきましたが、ビットコインやXRPレジャーは、それぞれの分散型台帳プラットフォームに搭載されている承認技術を用いて、非中央集権的な形で二重支払い問題を解決しました。

次に、二重支払い問題がどういったものなのか、下記で具体的に見ていきましょう！

技術的な話になってくると専門用語はどうしても避けては通れない道なんですよね…

下記で個々の専門用語をなるべく分かりやすく説明していきます。

まず、最初に出てくる…

ノード（Node）

…ですが、こちらは暗号資産関連の情報でよく出てくる用語で、私も最初は…

『ノードって一体なんぞや？』

…と思いましたが、ノードの同義語として、サーバーというものがあります。

サーバーだとノードよりかは、一般的に馴染みのある用語ですよね。

ノードはサーバーのことを指しており、サーバーとは、情報の保存や特定のプログラムやプロトコルの演算処理をするためのシステムのことを指しています。

た、確かにそうですね…

ノードやサーバーは、情報を保存するためのハードディスクや、計算問題を処理するための計算機や電卓のようなものとして考えると分かりやすいかもしれないです。

例えば、XRPレジャーのコンセンサス・アルゴリズムの各ノードは、XRPのトランザクション（送金・取引・決済）の記録や情報を保存したり、計算機や電卓と同じように決められたプログラムに沿ってXRPのトランザクションを処理しているのです。

・UNL
・バリデーター

…の説明は、下記で後述させて頂きます！

例えてもチンプンカンプンやで！

XRPのトランザクション（送金・取引・決済）やXRPの所在場所の情報は、100人の職員（ノード）によって記録・管理されています。

そして、100人の職員（ノード）のうち、30人が課長（バリデーター兼ノード）として、承認者の役割を果たしていると仮定します。

30人の課長（バリデーター兼ノード）たちは、XRPの各トランザクションを精査・承認するという、オフィス（XRPレジャー）で最も重要な役割を果たしています。

課長（バリデーター兼ノード）は、XRPの各トランザクションが正当なものであるか否かを精査した上で、有効だと判断したトランザクションを承認します。

課長（バリデーター兼ノード）により、正当であると承認を受けたXRPのトランザクションは、最終的に各職員（ノード）のノート（XRPレジャーの台帳）に正式に記録されます。

確かにそういうイメージになりがちですが、ちょっとだけ違います。

課長（バリデーター兼ノード）がXRPの各トランザクションを精査した上で、正当であると判断し、承認をしたXRPのトランザクションを職員（ノード）に向けて発表します。

職員（ノード）は、課長（バリデーター兼ノード）が発表したXRPのトランザクションを聞き取り、それをノート（XRPレジャーの台帳）に記録するというような感じです！

イメージとしては、オフィス（XRPレジャー）の前方に課長（バリデーター兼ノード）が30人、その後方に職員（ノード）が70人いて、課長（バリデーター兼ノード）は、職員（ノード）に向かって、ひたすら課長（バリデーター兼ノード）が正当であると判断し、承認をしたXRPのトランザクションを発表し続けている、というようなイメージです。

職員（ノード）は課長（バリデーター兼ノード）が発表し続けているXRPのトランザクションを聞き取り、ノート（XRPレジャーの台帳）に、聞き取ったXRPのトランザクションの記録を記していく、というようなイメージです。

とは言え、職員（ノード）は、課長（バリデーター兼ノード）が発表し続けているXRPのトランザクションの記録をそのままノート（XRPレジャーの台帳）に記しているというわけではありません。

それは、課長（バリデーター兼ノード）が正当であると判断し、発表をし続けているXRPのトランザクションが、その時点では、必ずしも100％正当なものであるという結論にはまだ至っていないからです。

コンセンサス・アルゴリズムの最初の段階、つまり、どのXRPのトランザクションが正当であるかを判断する最初の段階のことですが、課長（バリデーター兼ノード）が正当であると判断し、承認をしたXRPのトランザクションは、あくまでも、個々の課長（バリデーター兼ノード）による個別の判断であるため、30人の課長（バリデーター兼ノード）間で、その時点では、まだ最終的な合意形成には至っていません。

次に、30人の課長（バリデーター兼ノード）間で、どのようにして、任意のXRPのトランザクションが正当であると判断され、承認の最終的な合意形成に至るのか、を見ていきましょう。

今回の例では、簡略化のため、課長（バリデーター兼ノード）により、職員（ノード）に対して行われているXRPのトランザクションの発表は、青と赤の二択しかないと仮定します。

課長（バリデーター兼ノード）は、職員（ノード）に向かって…

『青！』

…あるいは…

『赤！』

…と発表をするのですが、一番最初の発表ですと、課長（バリデーター兼ノード）間の発表がバラバラの可能性があります。

そうすると職員（ノード）は、どのXRPのトランザクションの記録を正当なものとしてノート（XRPレジャーの台帳）に記すか、混乱してしまいますよね？

なので、課長（バリデーター兼ノード）による発表は、何回かのラウンドに渡って複数回行われます。

課長（バリデーター兼ノード）は、何回かに渡って発表をし続けていくうちに、他の課長（バリデーター兼ノード）の発表と自身の発表を照らし合わせられることができるので、当初はバラバラだった発表が一つの統合された発表に収斂し、最終的には合意形成に至るのです。

このような過程を通じて、課長（バリデーター兼ノード）間での合意形成によるXRPのトランザクションの承認を行うので、合意形成を意味する…

コンセンサス

…に至るためのアルゴリズムということで、コンセンサス・アルゴリズムと称されるに至ったのです。

ちなみに、コンセンサス・アルゴリズムでは、とあるXRPのトランザクションが最終的に正当なものであると判断され、承認されるには、課長（バリデーター兼ノード）間で80％の合意形成が必要とされています。

なので、これまでの例に則ると、とあるXRPのトランザクションが正当なものであると判断され、承認されるには、30人の課長（バリデーター兼ノード）のうち、24人が正当であると判断し、合意形成に至らなくてはいけないのです。

確かにそういう印象を受けるかもしれませんが、課長（バリデーター兼ノード）たちは、しっかりとした論理的な理由に基づいて発表を変更しています。

課長（バリデーター兼ノード）たちが発表を複数回のラウンドを通じて行っていくうちに、なぜ各課長（バリデーター兼ノード）たちが発表の内容を変更するのか、また、どのようにして当初はバラバラだった発表が一つの統合された発表に収斂し、最終的には合意形成に至るのか、下記の例で説明します。

学校の授業中、先生がクラス全体に対して問題を問いかけることがありますよね？

例えば、先生が…

『1+1は〜？』

…とクラス全体に問いかけたとします。

恐らくクラスの大多数の生徒は一斉に…

『2！』

…と回答をするでしょう。

しかし、クラスの何人かの生徒が間違って…

『3！』

…と回答をしてしまったとしましょう。

誤った回答をしてしまった数人の生徒たちは、まず、自身の回答が全体のうちの少数派であるということに気付き、その後、他の大多数の生徒が行った回答の方が正しいということを認識し、自身の回答が誤っていたことに事後的に気付きます。

それは、自分自身で気付くこともありますし、先生や他の生徒からの指摘によって気付くこともあります。

重要な点は、間違った回答をしてしまった生徒が、自身の回答が少数派であるということに加えて、自身の回答が誤っていることに気付き、認識を改める機会が設けられているということです。

そこで、先生がもう一度同じ問いかけをしたらどうなるでしょうか？

当初誤った回答をしてしまった数人の生徒たちは、最初の誤りを鑑み、二度目の回答をする際には正しい回答をするので、クラス全体が一つの正しい回答に収斂していきます。

かなり簡略化された例ですが、コンセンサス・アルゴリズムにおいて、バリデーター間で合意形成に至る際にも（コンセプト上）上記と同じような事象が起きているのです。

課長（バリデーター兼ノード）による発表を複数回のラウンドに渡って行うことで、上記と同じような形で、課長（バリデーター兼ノード）間の発表が一つのまとまった発表に収斂していき、合意形成に至るのです。

そこで重要となってくるのが、UNL（ユニーク・ノード・リスト）なのです！

これまでの例に則ると、UNLにより、職員（ノード）は、どの課長（バリデーター兼ノード）の発表を聞きたいか指定することができるので、職員（ノード）は、選択をした一部の課長（バリデーター兼ノード）による発表しか聞かなくて済むようになるのです。

例えば、とある職員（ノード）が、30人の課長（バリデーター兼ノード）の内、5人の課長（バリデーター兼ノード）を指定したとすると、その職員（ノード）の耳には、指定をした5人の課長（バリデーター兼ノード）による発表しか入ってこなくなるので、残りの25人の課長（バリデーター）による発表は聞かなくて済むようになるのです。

まず、大前提として、XRPレジャーはオープンなプラットフォームなので、（理論上）誰でもバリデーターになることができるのです。

なので、（理論上）悪意のあるバリデーターが存在しうる可能性もあるのです。

当然、XRPレジャーのコンセンサス・アルゴリズムには、そういった悪意のあるバリデーターを排除するための機能が備わっています。

例えば、悪意のあるバリデーターが、故意にXRPのトランザクションの精査・承認作業を混乱させようとした場合、その行為は検知され、その悪意のあるバリデーターが無効になるよう設定されています。

また、UNLの最大の意義は、バリデーター間における何らかの結託・企み・談合を防ぐことです。

例えば、利害関係が密接に関わり合っているバリデーターが複数存在するとします。

それら利害関係が密接に関わり合っているバリデーターが、何らかの結託・企み・談合をする可能性はゼロとは言い切れないので、何らかの結託・企み・談合をする恐れがあるバリデーターを、あえて同じUNLに入れないことで、バリデーター間における何らかの結託・企み・談合の恐れを払拭することができます。

各ノードは、任意のバリデーターを選択して、任意のUNLを構成することができます。

ちなみに、デフォルト・UNLと呼ばれる、リップル社が推奨するバリデーターで構成されているUNLが存在します。

デフォルト・UNLは、社会的信用度が高く、また、XRPのエコシステムの拡大・拡張に資する存在として位置付けられているバリデーターによって構成されています。

もちろん、上記のデフォルト・UNLを選択するか否かの判断は任意なので、最終的にはノード側に帰属します。

とあるXRPのトランザクションに対して、80%以上の課長（バリデーター兼ノード）が、正当なもであると判断をし、合意形成に至ると、そのXRPのトランザクションは承認されます。

XRPのトランザクションが承認されますと、先述した通り、課長（バリデーター兼ノード）を含む100人の職員（ノード）の机上に置かれているノート（XRPレジャーの台帳）に、新しく承認されたXRPのトランザクションが記され、また、ノート（XRPレジャーの台帳）に記録されている、XRPの所在場所に関する情報も更新されます。

職員（ノード）の机上に置かれているノート（XRPレジャーの台帳）の一番新しいページ（最後に更新されたページ）は…

ラスト・クローズド・レジャー（Last Closed Ledger）（以下：LCL）

…と呼ばれており…

最後にクローズド（更新された）台帳

…を意味します。

このLCLこそが、最新のXRPのトランザクションが記載された台帳であり、LCLが発行されますと、上記で説明してきたXRPのトランザクションの精査・承認のプロセスが再び最初から開始します。