Remmeにゾッコン、買い増し継続中のハッシュ（@e_hash104）です。
今までRemme（レミー）のことはずっと追ってきましたが、どこかみんなに上手く伝えられてない感じがしてました。ハッシュは技術屋ではないので、IT用語がズラリと並んだ文章とか理解するのが相当厳しいです…。
ですが、Remme Protocol Technical Paper が公開されたとあったら、もうジッとしていられませんでした。これがあれば、日本の人たちにもっとRemmeを知って貰える。そう思ったのです。
原文をもとに、翻訳を始めたのですがそもそも色んな専門用語（英語も日本語も）でつまづきます。Google先生も見ながらやったのですが、あの文章で理解できる人は居ないでしょう（笑）
でも、時折美しい翻訳を見せるので、そういう箇所は利用させてもらっています。あと自分がつまづいた所は、みんなもその意味がわかるようにしてあります（カーソルを乗せると解説が(ポップアップされます）。
分からない所も出てくるでしょうが、どうかがんばってついて来てください。踏ん張って理解しようとする時にこそ、知識は深まっていきます。
きっとRemmeだけでなく、他のブロックチェーンのプロジェクトを理解するのにも役立つと思います！
これを作ってくれたRomanに感謝です…。
要旨
Remmeプロトコル・ソフトウェアは、ブロックチェーンの基本設計を導入し、分散型アプリケーション（プログラム）の縦横無尽な スケーリング を可能にします。このことは、アプリケーションを作成できるOSのような構造を造ることによって、実現可能となります。
ソフトが提供するものは、アカウント、認証、データベース、非同期通信 、たくさんのCPUコアやクラスターをまたぐアプリケーションの スケジューリング となります。
その結果として得られる技術こそが、究極的には１秒間に数百万回というトランザクションまで拡張させることが可能なブロックチェーンアーキテクチャ（基本設計）であり、ユーザーによる使用料をなくし、且つ管理者側の都合で分散型アプリを迅速に、しかも容易に展開したり、メンテナンスしたりできるようにするものなのです。
注意事項：ここで言及されているトークンは、ICO当時から流通しているERC20ベースのREMではなく、新しく作られるメインネット上で採用されるREMのことを意味しています。
背景
Remmeプロトコルは、ブロックチェーン技術を用いて既存の中央集権的な公開鍵基板（以下、PKI）の手法を、ブロックチェーンをベースとした「信頼のネットワーク」にとって変えようとしているのです。
はじめるにあたって、適切なプラットフォームの選択はどのブロックチェーンプロジェクトにとっても必須要件です。実際のビジネスにおいては、多機能製、適応性、スケーラビリティ、セキュリティ、コミュニティサポートがそれぞれの要件に合ったブロックチェーンを選択することが不可欠です。
入念に検討した結果、我々Remme TeamはRemme PKIソフトウェアを構築するのに最適なプラットフォームであるとしてEOSIOコードベースに決定しました。最も知られた暗号資産のひとつであるEOSエコシステムは、EOSIOコードベースはによって現在も稼働しています。
結果として、それは非常に高いレベルで敵対的な攻撃に対してテストされており、業界で大きな評価を得ています。
拡張性を考慮して設計されたEOSIOは、毎秒数千回のトランザクションを処理でき、限りはあるものの無料で利用できるトランザクション、遅延の少ないブロック確認（0.5秒）、ビザンチンフォルト耐性がありながらもそれに附随する処理を少なくし、階層的で役割ベースの許可や、ブロックチェーン通信間への注力を提供しています。
これらの要素がゆえに、RemmeプロトコルソフトウェアはEOSIO上に作られるのです。この文書では、EOSIOに由来する機能と、Remmeプロトコルによってもたらされる機能について説明されています。
ブロックチェーンアプリケーションの必要要件
広く使ってもらうために、ブロックチェーン上のアプリケーションは以下の要件を満たすのに十分な柔軟性が求められます。
何百万人といユーザーをサポート
中央集権型ビジネスと競合するためには、毎日何千万人というアクティブユーザーを処理出来るブロックチェーン技術が必要です。
特定の場合において、場合によっては、アプリケーションが限界量のユーザーに到達しない限り機能しない可能性があるため、非常に多数のユーザーを処理できるプラットフォームが最も重要です。
無料利用枠
アプリケーション開発企業は、ユーザーが無料で使えるサービスを提供できる柔軟性を必要としています。というのも、ユーザーはプラットフォームを利用したり、そのサービスを活用したりするために使用料を払うべきではないからです。
ユーザーが無料で利用できるブロックチェーンプラットフォームは、より広範に普及する可能性があります。その結果、開発陣や企業は効果的なマネタイズ戦略を採用することができるようになります。
簡単なアップグレードとバグ修正
ブロックチェーンベースのアプリケーションを構築する企業は、新しい機能を備えたアプリケーションを強化できる柔軟性を必要としています。プラットフォームはソフトウェアと スマートコントラクト のアップグレードをサポートしなくてはなりません。
簡単に例えると自動販売機のようなもので、「決められた金額を投入する」「欲しい商品のボタンを押す」「自動的に商品が提供される」という一連の流れをイメージしてもらうと分かりやすいかもしれません。
同じことをより複雑なプロセスでやろうとしているのが、スマートコントラクトという訳です。
全ての重要なソフトウェアには、バグはつきものです。それは、例え最も厳密な形式の検証を行ったものでさえもです。プラットフォームはどうしても発生してしまうバグを修正できるだけの堅牢性が求められます。
低レイテンシ
優れたユーザーエクスペリエンスには、数秒以内に収まる遅延のみといった信頼性の高いフィードバックが求められます。
遅延（=レイテンシ）が長くなれば長くなるほどユーザーは不満を抱え、結果としてそのブロックチェーンベースのアプリケーションは既存のブロックチェーンを用いていない代替品に対してより優位性を失っていきます。
プラットフォームは遅延少なく処理できる高速性を維持できるようにするべきなのです。
シーケンシャルパフォーマンス
シーケンシャルでないと処理できない行程が含まれているせいで、並列アルゴリズムを実行出来ないアプリケーションというのが存在します。
取引所のようなアプリケーションにおいては、扱う処理数が膨大なため相応のシーケンシャルパフォーマンスが求められます。それゆえ、プラットフォームは高速なシーケンシャルパフォーマンスをサポートする必要があります。
パラレルパフォーマンス
規模の大きなアプリケーションにおいては、作業負荷を複数のCPUやコンピューターに分散させる必要があります。
コンセンサスアルゴリズム（BFT-DPOS）
Remmeプロトコルソフトウェアは DPOS と呼ばれるブロックチェーン上の PKI アプリケーションに必要な性能要件を満たすことができると実証済みである分散型の コンセンサスアルゴリズム のみを利用します。
このアルゴリズムのもとでは、そのプロトコルソフトウェアを採用しているブロックチェーンにおいて一定量のトークンを保有している人たちは、ブロックプロデューサー（以下、BP)と呼ばれるブロックを生成する人たちを絶え間なく行われている投票メカニズムを通じて選ぶ事ができます。
必要最低限のトークンを集めた人は誰でもブロックプロデューサーとなれるトップ21の地位に立候補するか、もしくは信頼がおけるもしくは納得のいく他の立候補者に投票するかを選ぶことができます。
積極的にネットワークの安定に貢献する（コンスタントに投票し、いつも必要最低限のトークンをステーキングしている）ことが、報酬分配プロセスに参加するための要件です。
投票の持つ影響力は、ステーキングしているトークン数に比例します。つまり、よりたくさんステーキングすれば、それだけあなたの投票が影響力を持つということです。
ブロックプロデューサーを選ぶプロセスを伴うこの統治システムによって、トークンホルダーは委任され、最も信頼でき、プロフェッショナルであるブロックプロデューサーへの立候補者を選ぶ妥当なインセンティブを与えられることになります。
さもなければ、もし、選んだ立候補者が誤った行動をとり、ネットワークがエンドユーザーに質の悪いサービスを提供することになってしまった場合、トークンホルダーは経済的に深刻な損失を被ることになります。
Remmeプロトコルソフトウェアによって、きっちり0.5秒毎にブロックが生成され、たったひとりだけが任意の時点でブロックを生成することを許可されます。もしブロックが決められた時間内に生成されない場合は、その タイムスロット に割り当てられたブロックはスキップされます。
ひとつ、もしくは複数のブロックがスキップされた場合は、ブロックチェーン上に0.5秒、又はそれ以上のギャップが存在することになります。
Remmeプロトコルソフトウェアを使用して、ブロックは126ラウンド（６ブロックずつを21人のブロックプロデューサーによって）で生成されます。それぞれのラウンドのはじめに、トークンホルダーが気に入った人に票を入れることで21人のユニークブロックプロデューサーが選ばれます。
選ばれたブロックプロデューサーは、その中で15人以上のブロックプロデューサーによって合意された順序で組み込まれます。
もしブロックプロデューサーがブロック生成に失敗し、それまでの24時間でブロックを全く生成できていなかったとしたら、ブロック生成をする意志を再度ブロックチェーン上に示すまで、21人のブロックプロデューサーリストから外されることになります。
これにより、信頼できないと分かったブロックプロデューサーを予定に組み込まないことで生成に失敗するブロック数を最小限にし、ネットワークがスムーズに作動するようになります。
通常の状況下では、DPOSブロックチェーンはいかなる フォーク もしません。というのは、ブロックプロデューサーたちは、ブロックを生成するために競争しあうというよりむしろ協力し合うからです。
フォークが発生した場合、コンセンサス（合意）は自動的に最も長いチェーンに切り替わります。
この方法が機能するのは、フォークしたブロックチェーンに加えられるブロックの割合が、同じコンセンサスを共有するブロックプロデューサーの割合と直接相関関係にあるためです。
つまり、より多くの生成者がいる側のフォークしたブロックは、生成者の少ない側より速くチェーンが伸びていきます。これは、ブロックプロデューサーがより多くいるフォークの方が見逃されるブロックが少なくなるためです。
更には、いかなるブロックプロデューサーも同時に２つのフォークでブロックを生成するべきではありません。これをしたブロックプロデューサーは、おそらく除外される方向で投票されるでしょう。
そのようなブロックの二重生成をしたという暗号化された証拠を用いて、悪用者は自動的に排除されるかもしれません。
どのブロックプロデューサーも同じタイムスタンプや同じ ブロックの高さ にある２つのブロックに誰もサインしないかぎり、全てのブロックプロデューサーが全てのブロックにサインできるようにすることによって、従来のDPoSに ビザンチン・フォールト・トレランス （以下BFT）が加えられているのです。
一旦15人のBPがブロックにサインしたら、そのブロックは元に戻せないとみなされます。
BFT-DPoSは、考えられるあらゆる自然なネットワーク障害の中でも堅牢であり、またトークンを大量に保有する少数が起こす悪意ある問題に対しても安全性を確保できます。一部の競合アルゴリズムとは違って、BFTはブロックプロデューサーの大多数が失敗した時に機能し続けることができます。
このプロセスの間に、コミュニティはそのブロックプロデューサーが100%の参加を再開できるまで、その失敗したブロックプロデューサーの代わりに他の誰かを割り当てるよう投票することができます。
ブロックプロデューサー選出
- アクティブBP（選ばれたトップ21人）：ブロックチェーンに新しいブロックを生成し、追加する責任を有する。
- スタンバイBP：ブロックを生成することはないが、ある時点でアクティブBPになることはある。
- BPが票を入れる候補者を変更することは可能です。同様に、ネットワークへ十分なサービスを提供できていないBPを、自分の支持候補者からすぐに外すことができます。
- 同時に複数の候補者に票を入れることも可能です。しかし、その候補者達が受け取る投票数は均等に分配され、そのBPによってステークされたトークンの合計数と同じになります。
ブロックプロデューサーになる方法
Remmeプロトコルには、BPになるために満たすべき明確な基準があります。
- BPになるためには最低250,000REMをステークすること
- ステークしたトークンは６ヶ月間ロックされること（一旦ステーキングしたら変更不能）
初期のロック期間に更にBPがトークンを追加してステークした場合、比例してロック期間も延びます。たとえば、初期のロック期間である６ヶ月の間に、1億REMをステークしている口座が開設されたとします。
その１ヶ月半後に、更に２億REMを追加してステークしたとします。その結果、ロック期間は残り４ヶ月半だったものが、合計３億ステークしている状態で残り５ヶ月半に調整されます。
計算式は以下の通りです。
６ヶ月ー６ヶ月ｘ（（１億ｘ1.5/６ヶ月）/（１億＋２億））
ブロックプロデューサー辞退
BPであることを辞退し、その役割を放棄すると所有者が一旦決めた場合、システムコントラクト内のunregprodコマンドを呼び出す専用のトランザクションにサインする必要があります（ただし、最初の６ヶ月のロック期間は不可）
このあと、ステークされたREMトークンは６ヶ月にわたり徐々に戻されることになります。このようなことは、BP間における投機行動からネットワークを安全に保つために行われます
例えば、３億REMをステークしているBPがその役を降りたとします。２ヶ月後、その人は再度BPとして開始しようと決めました。２億REMがまだ保留されている状態ですので、そのトークンは再びステークされ、ロックはされてない状態へと戻ります。
もしBPがすでに手元に戻されているトークンを追加でステークしようとした場合、全てのステークが上述したような計算式に従って再びロックされることとなります。
アカウント
Remmeプロトコルソフトウェアは、人が読むことが可能な12文字までの固有な名前によって全てのアカウントを参照できます。その名前は、アカウントを作成した人が選べます。
分散型の コンテキスト においては、アプリケーション開発者は新規ユーザーが利用を開始するためにアカウントを作成すると僅かながらコストがかかります。従来の企業は、広告、無料サービス等といった形で顧客ひとり当たりに対してかなりの金額を既に費やしています。
新規ブロックチェーンアカウントの資金調達コストは、それと比較してわずかなものです。幸いなことに他のアプリケーションで既に登録しているユーザーは、アカウントを新たに作る必要はありません。
アクション＆ハンドラ
各アカウントは他のアカウントに構造化されたアクションを送る事ができ、受信時にアクションを処理するスクリプトを定義したりできます。Remmeプロトコルソフトウェアは、各アカウントに対し独自のデーターベースを提供し、そこには独自のアクション ハンドラ でしかアクセスできません。
アクション処理スクリプトは、他のアカウントにアクションを送信することもできます。アクションと自動アクションハンドラの組み合わせは、Remmeプロトコルがどのようにアクションハンドラを定義するかということになります。
並列実行をサポートするために、各アカウントはデータベース内のどんな数字の スコープ でも定義できます。BPはアクセスメモリにおける競合が発生しないようにトランザクションをスケジュールすることで、並列的に実行することができます。
役割ベースの権限管理
権限管理にはアクションが適切に承認されているかどうかを判断することが含まれます。もっとも簡単な形式の管理権限は、トランザクションに必要な署名があるかどうかをチェックすることですが、これは必要な署名がすでに分かっている事を意味しています。
一般的に、権限は個人や個人で形成されるグループに限定され、しばしば区分化されます。Remmeプロトコルソフトウェアは、アカウントに「誰が、何を、いつ」行うのかということをきめ細やかで、ハイレベルなコントロール制御を可能にする宣言型権限管理システムを提供します。
認証と権限管理を標準化し、アプリケーションのビジネスロジックから切り離すことが重要です。これにより、汎用的な方法で権限を管理するためのツールを開発することができ、またパフォーマンスを最適化するための重要な機会が得られます。
全てのアカウントは、他のアカウントと秘密キー（秘密鍵）を加重しながら組み合わせることによって制御されることがあります。これにより、権限が実際にどのように編成されているかを反映した階層的な権限構造が作成され、アカウントに対するマルチユーザー制御がこれまでになく簡単になります。
マルチユーザー制御はセキュリティに関して最も影響を与える要素であり、適切に管理さえされれば、ハッキングによる盗難のリスクを大幅に減らすことが可能です。
アカウントはRemmeプロトコルソフトウェアを利用する事で、どんなキーとアカウントの組み合わせである特定のアクションタイプを他のアカウントに送信できるかを定義できます。
例えば、あるユーザーのSNSアカウント用のキー１つで、取引所へのアクセスに必要なキーの役割を合わせ持つことができます。他のアカウントにキーを割り当てずに、ユーザーのアカウントに変わって行動する許可を与えることも可能です。
名前付き許可レベル
Remmeプロトコルソフトウェアを使うことで、アカウントは名前付き許可レベルを定義でき、各レベルはより高いレベルの名前付き許可レベルから派生できます。各名前付き許可レベルは権限を定義します。
その権限は、キーや他のアカウントの名前付き許可レベル、あるいはその両方で構成される、しきい値 が複数の署名からなるチェックです。
たとえば、あるアカウントの「友だち」という名前の付いた許可レベルを、『行動』をとるという風に設定し、そのアカウントの友だちは誰でも同様に制御できます。
権限マッピング
Remmeプロトコルソフトウェアによって、各アカウントは他のアカウントの「コントラクト/アクション」または「コントラクト」と独自の名前付き許可レベルとの間の マッピング 定義ができます。
たとえば、あるアカウントホルダーが自身のSNSアプリケーションを自分のアカウントの「Friend」と名付けている許可グループにマッピングすることができます。このマッピングをすることで、友だちは誰でもアカウントホルダーとしてその所有者のものであるSNSに投稿することができるのです。
彼らはアカウントホルダーとして投稿できるわけですが、彼らは「アクション」にサインするために依然として自分自身のキーを使用します。これが意味するところは、どの友だちがどのようにそのアカウントを使ったのかを常に特定できるということです。
権限の評価
Remmeプロトコルソフトウェアは、「Action（アクション）」と名付けられた行動を@aliceから@bobに送るとき、まず最初に@aliceが@bob.groupa.subgroup.Actionに対して許可権限を定義しているかどうかをチェックします。
もし何も定義されていない場合、@bob.groupa.subgroupのマッピングを検索し、それでも無い場合は@bob.groupa、最終的には@bobがチェックされることになります。それでも何もマッチしなければ、想定されるマッピングは名前付きの許可グループ@alice.activeへのものとなります。
一旦マッピングが識別されると、次に署名権限機関はしきい値署名プロセスと、名前付きの許可に関連付けられた権限を用いて検証されます。もしそれが失敗した場合は、上位の許可（parent permission）にうつり、最終的にはオーナー許可にあたる@alice.ownerにまでいきます。
デフォルトの権限グループ
Remmeプロトコル技術によって全てのアカウントが何でも可能な「オーナー」グループと、オーナーグループを変更する以外は何でもできる「アクティブ」グループを持つことができます。それ以外の全ての許可グループは「アクティブ」グループから派生しています。
権限の並列評価
権限の評価工程は「読み取り専用（read-only）」で、トランザクションによって行われた権限への変更はブロックの終わりまで有効になりません。これが意味するところは、全トランザクションに対する全てのキーと権限評価は並列に実行されるということです。
さらに、ロールバック する必要があるような負荷の大きいアプリケーションロジックを起動することなく、権限の迅速な検証が可能になります。最後に、保留中のトランザクションが受信されたときにトランザクションの許可が評価でき、適用されるときには再評価する必要がないことを意味します。
全てを考慮に入れると、許可の検証はトランザクションの検証に必要な計算のかなりの割合を占めるということです。これを「読み取り専用」とし、簡単に並列か可能なプロセスにすると劇的にパフォーマンスを向上させることができます。
アクション・ログから確定的な状態を再生成するためにブロックチェーンを再生するときに、権限を再評価する必要はありません。このステップをスキップするには、トランザクションが既知の健全なブロックに含まれているという事実だけで十分です。
このことは、増え続けるブロックチェーンを再生する際に伴う計算不可が激減されます。
データベースののトランザクション処理において、処理の途中で不具合が起きた場合などに、そもそもその処理をやらなかったことにしてそのトランザクションの前までもどること
強制遅延のあるアクション
これはセキュリティにおける最重要要素です。多くの場合、秘密鍵が盗まれたのを知るのは、使われてはじめて知る事ができます。時間ベースのセキュリティは、日常的に使用するためにインターネットに接続されているPCにキーを保存する必要がある場合は更に重要になってきます。
Remmeプロトコルソフトウェアを使用すると、アプリケーション開発者は、特定のアクションがブロックに加えられてから適用できるようになるまでに最小限度ではあるが待ち時間が発生することを示すことができます。この間に、キャンセルも可能です。
これらのアクションの１つが ブロードキャスト されると、ユーザーはメールやテキストメッセージにて通知を受けることが可能です。承認しなかった場合は、アカウント回復プロセスを使用してアカウントを回復し、アクションを取り消すことができます。
必要な遅延は、操作にどれだけスピードが求められるかによって異なります。珈琲代を支払う際には遅延などいらないですし、数秒で元に戻せなくなることもありえます。その一方で家を買うときなどは、72時間の精算期間が必要かもしれません。
アカウント全体を新しいコントロールにイカンするのに最大で30日かかる場合もあります。適正な遅延期間はアプリケーション開発者とユーザーによって選択されます。
盗まれたキーからのリカバリ
Remmeプロトコルソフトウェアは、キーが盗まれた場合、アカウント制御を回復させる方法をユーザーに提供します。
アカウント所有者は、過去30日間にアクティブであった任意のオーナー・キーを指定のアカウントリカバリパートナーからの承認をもって、自分のアカウントのオーナー・キーをリセットできます。
アカウントリカバリーパートナーは、所有者からの依頼なしにはアカウント制御のリセットは行えません。
ハッカーがリカバリープロセスをパスしようとしても得る物は何もありません。というのも、ハッカーは既にそのアカウントを「制御」しているのですから。
更に言えば、万が一そのプロセスをパスしたとしても、リカバリーパートナーはIDや複数の認証要素（電話番号やメルアド）を要求する可能性があります。
これはおそらくハッカーを危険にさらします。すなわち、このプロセスからは何も得る物は無いということです。
このプロセスは、そもそも単純な マルチシグ 構成とは大きく異なります。マルチシグトランザクションでは、実行されるトランザクションの一つ一つに対して別の エンティティ が参加します。
それとは対照に、リカバリープロセスにおいては、リカバリーパートナーはそのリカバリープロセスの当事者に過ぎず、日々のトランザクションに対しては権限を持ちません。こうすることで、関係者全員のコストと法的責任が劇的に削減されます。
トークンモデルとリソース使用
全てのブロックチェーンにはリソースに制限があり、悪用を防ぐためにシステムが必要です。Remmeプロトコルソフトウェアを使用するブロックチェーンでは、アプリケーションによって消費されるリソースは大きく３つに分けられます。
- 帯域幅 とログストレージ（Disk）
- 計算と計算バックログ（CPU）
- ステートストレージ（RAM）
帯域幅と計算は、即時使用と長期使用という２つの要素をもっています。
ブロックチェーンには全ての「アクション」のログが残っており、このログは最終的に全てのフルノードによって保存、およびダウンロードされます。
アクションログを使って、全てのアプリケーションの状態を再構築することが可能です。
コンピュテーショナル・デット（Computational Debt：EOSでの技術的な言葉）は、アクションログから状態を再生成するために実行する必要がある計算から発生します。
もし、コンピュテーショナル・デットが大きくなりすぎると、ブロックチェーンの状態をスナップショットで収めて、ブロックチェーン上の履歴を破棄する必要がでてきます。
もしくは、コンピュテーショナル・デットが急速に大きくなると、１年分のトランザクションを再生するのに半年もかかることがあります。
したがって、コンピュテーショナル・デットを慎重に管理することが重要になってきます。
ブロックチェーン・ステート・ストレージ（状態の記憶のこと）は、アプリケーションロジックからアクセスできる情報のことです。これには、デジタルキーや失効状態、口座残高といった情報を含みます。
もしアプリケーションが状態を全く読み込めない場合は、保存しないようにしてください。
たとえば、IDスキャンや家の住所などをアプリケーションロジックが読み込まない場合は、保存すべきではありません。
一方で、ドキュメントの有無、投票数、その他のプロパティはブロックチェーンの状態の一部として保存されるべきものです。
Remmeプロトコルソフトウェアを採用すると、帯域幅と計算容量は一時的なものとなるため、フラクショナルリザーブ方式で割り当てられます（未使用の容量は将来使うために残しておくことはできません）
EOSブロックチェーンと比較して、Remmeプロトコルソフトウェアは簡素化されたリソース管理エクスペリエンスを提供します。
Remmeでは主にPKIのユースケースに重点を置いているため、ネットワーク内の主力サービスはスマートコントラクトに基づくBPたちによって提供され、ほんの少しの割合だけがその主力サービス上で成り立つコミュニテイdAppによって提供されることとなるはずです。
これに対処するために、Remmeプロトコルでは供給可能なリソース（RAM, CPU, NET）を最低３日間ステークしているトークンの数に比例して、しかも同時に割り当てます。
たとえば、全トークン供給量の１％がステークされているとして、あるアカウントは１%相当の全リソースを使うことができます（自分のdAppを実行するか、または他の誰かのdAppをしようすることで）。
ユーザーのスマートコントラクトとは反対に、システムコントラクトが提供するのは継続課金または使用毎のモデルに基づいて様々なPKIサービスとなります。
たとえば、ユーザーはデバイスの公開鍵とその失効ステータスを１年間保存するために一定の固定料金を支払います。その期間終了後、その公開鍵は期限切れのステートに移されて、システムコントラクトによってそのRAMリソースが開放されます。
Remmeプロトコルは固定料金でアカウントを開設できます。新規アカウントユーザーは、追加料金無しでアカウントデータを保存し、１日平均で３〜５回のトランザクションを実行できるようにするため、必要最小限度のCPU,NET,RAMリソースを割り当てています。
目標とするところは、大多数（最大95%）のユーザーが無料で使えるようにすることです（おそらく通常のユーザーは１日５回のトランザクションで十分だと考えています）
このリソース管理の煩わしさを取り除き、ユーザーエクスペリエンスを単純化するこによって、Remmeプロトコル上で実行されているブロックチェーンが、ブロックチェーン技術とその特殊性に馴染みのない初心者にとってとっつきやすく、直感的に感じてもらえると我々は信じています。
このようなアプローチで、その背後で動いているブロックチェーンに気づくこと無くほとんどのユーザーがさまざまな高レベルのアプリケーションにアクセスできるようになることを我々は期待しています。
セキュリティの向上や他のPKIユースケースの恩恵を受けている企業やdAppによってほとんどのユーザーが利用を開始し、そのユーザー達がもし新たに新規アカウントが必要であれば有料プランを利用してくれることを我々は望んでいます。
客観的および主観的測定
先述したように、計測使用量を計測することは、パフォーマンスと最適化に大きな影響を与えます。それゆえ、全てのリソース使用量の制限は、究極的には主観的であり、適用は個々のアルゴリズムと見積もりに従ってBPによって行われます。これらは通常、カスタムプラグインを書くことでBPによって実装されます。
とは言っても、客観的に測定できるものもいくつかあります。伝達されるアクションの数と内部データベースに保存されているデータサイズなどは客観的に測定するのが安価です。
BPはRemmeプロトコルソフトウェアを使うことによって、これらの客観的測定値に対して同じアルゴリズムを適用することはできますが、主観的測定値に対してより厳密な主観的アルゴリズムを適用することを選択できます。
受信者払い
伝統的に、オフィススペースや処理能力、経営をする上で必要なその他のコストなどを支払うのは企業です。顧客が企業から特定の商品を購入し、その販売売上から得られる収入が企業の運営コストをカバーするために使われます。
同様に、ウェブサイトを訪問する閲覧者に対し、ホスティング費用をカバーする目的で少額課金を強要するウェブサイトはありません。それゆえ、dApp（分散型アプリケーション）でも顧客に対してブロックチェーンを使うことためだけの目的でブロックチェーンに課金するべきではないのです。
Remmeプロトコルソフトウェアを利用している発売されたブロックチェーンは、ユーザーに対してブロックチェーンの使用自体に支払いを求めることはないので、企業が自社製品の独自の収益化戦略を決定することを制限したり、妨げたりすることはありません。
受信者が支払うことができるのは事実ですが、Remmeプロトコルでは送信者がその帯域幅、計算及びストレージに対して支払うことを可能にしています。これにより、アプリケーション開発者はアプリケーションに最適な方法を選択できます。
多くの場合には、送信者側が支払うモデルを採用することによって独自の配給システムを実装したくないアプリケーション開発者の複雑さを大幅に削減できます。アプリケーション開発者は、帯域幅と計算をユーザーに委任してから、「送信者払い」モデルの使用を強制させることができます。
エンドユーザーの観点からは無料ですが、ブロックチェーンの観点からは送信者払いモデルです。
委任要領
Remmeプロトコルソフトウェアを採用して立ち上げられたブロックチェーンにおけるトークン所有者は、利用可能な帯域幅の全てもしくは一部を直ちに消費する必要はないかもしれませんが、その使っていない帯域幅を他人に委任したり、貸したりできます。
すなわち、そのようなブロックチェーン上でRemmeプロトコルソフトウェアを稼働しているBPは、この容量の委任を認識し、それに応じて帯域幅を割り当てます。
トランザクションコストとトークン価値との分離
Remmeプロトコルソフトウェアによって受ける主な恩恵のひとつが、アプリケーションで利用できる帯域幅の量がトークンの値段に完全に影響を受けないということです。
もしアプリケーション所有者がRemmeプロトコルソフトウェアを採用したブロックチェーンに妥当な数のトークンを保有している場合、アプリケーションは固定された状態と帯域幅の使用内で無期限に実行できます。
このような場合、開発者とユーザーは相場のトークンプライスにおけるボラティリティに影響を受けることもないので、価格フィードに依存しません。
つまり、Remmeプロトコルソフトウェアを採用しているブロックチェーンにより、BPはその価値とは切り離されているトークンあたりの帯域幅、計算、ストレージを自然と増やす事ができます。
Remmeプロトコルソフトウェアを使用しているブロックチェーンでも、BPがブロックを生成する度にネットワークで獲得したトークンでリワードを受け取れます。
トークン価値は、生成者が購入可能な帯域幅、ストレージ、及び計算量に影響を与えます。すなわち、このモデルはネットワーク性能を向上させるためには、トークン価値も自然と上昇するようになっているのです。
状態ストレージコスト
ユーザーアプリケーションの状態を保存するには、その状態が削除されるまでアプリケーション開発者がトークンを保有している必要があります。状態が全く削除されない場合、トークンは循環から事実上削除されます。
ブロック報酬
ブロック報酬は以下の割合でブロックプロデューサー（BP）間で分配されます。
- 70% ー 全てのBP（アクティブとスタンバイ）でステークしているトークン数に応じて分配される
- 20% ー アクティブBP（トップの21人）間で受け取った投票数に応じて分配される（１トークン=１票）
- 10% ー Remmeの貯蓄口座
例えば、以下のような条件があるとします。
| 発行証明書の総額 | $100,000 |
| 自分自身に対する投票数 | 800,000 REM |
| 他BPから自分への投票数 | 4,200,000 REM |
| 自分のステーク数 | 1,000,000 REM |
| BPの総ステーク数 | 400,000,000 REM |
| 全アクティブBPの投票数 | 350,000,000 REM |
このような条件下でだとすると、まずは一定期間内（今回は１ヶ月を想定しました）に発生した総額（表の最上段部分）の大まかな内訳から紹介します。
- 70% ー 70,000 USD（BP全員でステーク量に応じて分配）
- 20% ー 20,000 USD（アクティブBPのみで投票数に応じて分配）
- 10% ー 10,000 USD（Remmeの口座へ）
※投票数は自分のステーク量を上限に、自分にどれだけ投票を入れたいかをまず決めます。そしてその残りは自分が投票したい他のBPに均等に振り分けなければなりません。今回、自分に80万、残り４人に投票をしたいので各５万ずつ分配します。
あとは、公式に当てはめるだけ。
今回の場合、ハッシュは100万REMをステーク及び投票しているので、以下のようになります。
1,000,000÷400,000,000 X $70,000 = $175
ハッシュが万が一アクティブBPだった場合は以下の公式が適用されます。
(4,200,000 + 800,000)÷350,000,000 X $20,000 = $285.71
$175 + $285 = $460（小数点以下省略）
以上が、具体例を交えたハッシュの補足でした。話をこの技術書に戻します。
BPの状態を維持するために、全てのBPは毎週投票を再表明しなくてはなりません。１週間以上にわたり票を更新しないBPは…
- BPはブロック報酬を受けられなくなる
- 最後に記録された投票の影響は、毎年半分ずつ減少する
ブロック報酬は、システムコントラクト方法で報酬請求することでアカウントに入金されます。報酬は流動的で、BPによって別のトランザクションとしてステークされることもあります。
BPがブロック生成に失敗したら報酬は得られません。報酬請求方法は、BPによってブロックチェーンに加えられたブロックの数に比例して報酬を加算します。その残り（ブロック生成に失敗した分の報酬）は、Remmeの貯蓄口座に入金されます。
凍結口座
スマートコントラクトは、時に異常な、もしくは予測出来ない形で作動し、意図したとおりに動いてくれないということがあります。また別なときには、アプリケーションやアカウントが不当な量のリソースを消費しているような悪用を発見することもあります。
そのような問題が避けられない場合は、BPはそのような状況を是正する権限を持っています。
全てのブロックチェーン上にいるBPは、どのブロックチェーンをブロックに含めるか選択する権限を持っているため、アカウントを凍結することができます。
Remmeプロトコルソフトウェアを使用しているブロックチェーンは、アカウントを凍結するプロセスをアクティブBP21人のうちの15人から票を集めることによって、この権限は有効化されます。
もしBPがこの力を悪用すると、そのBP達は投票によってはじかれ、被害にあったアカウントの凍結は解除されます。
アカウントコード変更
もう他に手段がなく、予想不能なかたちでアプリケーションが誰にも止められない状態になった場合、Remmeプロトコルソフトウェアを使用するブロックチェーンではブロックチェーン全体をハードフォークすることなく、アカウントコードを置き換えられるようにできます。
口座凍結のプロセスと同様に、このコードの置き換えには21人の選出されたBPの内15人の投票が必要となります。
ユーザー規約
Remmeプロトコルソフトウェアは、それに署名するユーザー間で「合意」と呼ばれる P2P 利用規約または拘束力のあるコントラクトを可能にします。
この合意内容はユーザー間の義務を定義していて、それは他の相互に認められた規則と共に、管轄権及び法律の選択を確立することによって紛争解決を促進するものです。
ネットワーク上でやりとりされる全てのトランザクションは、署名の一部として契約のハッシュを組み込む必要があり、それによって署名した人がそのコントラクトと明確に関連付けられます。
この契約では、プロトコルソースコードと意図することを人間が読めるように定義してあります。ここに書かれているものが、エラーが起きたときに、バグと機能の違いを識別し、どんな修正が適切で、どんな修正が不適切であるかについてコミュニティを導いてくれます。
プロトコルのアップグレード
Remmeプロトコルソフトウェアは、正規のソースコードで定義されているプロトコルを更新するためのプロセスを以下のように定義しています。
- BPはコードの変更を提案し、最低21人中15人の承認を得ること
- BPは30日連続で新しいコードの承認に必要な21人中15人の承認を維持すること
- コード変更は７日後に有効となり、ソースコード承認後１週間で全てのブロック生成をしないフルノードに対してアップグレードを許可すること
- この新しいコードへのアップデートを行わないノードはすべて、自動的にシャットダウンされること
緊急の変更
積極的にユーザーに害を及ぼしている有害なバグやセキュリティの悪用を修正するために必要な修正をソフトウェアに行う必要がある場合、BPはプロセスを速めることが可能です。
結論
Remmeプロトコルソフトウェアは、実証済みの概念と業界標準を用いた経験から設計されており、ブロックチェーン技術の根本的な進歩を体現しています。
このソフトウェアは、分散型アプリケーションを簡単に活用・管理できる世界規模の拡張性を備えるブロックチェーン社会に向けての青写真全体のほんの一部に過ぎないのです。
参照
この文章は、EOS.IOの資料に基づいて作成されています。
ハッシュのまとめ
ここまで読んでくれてありがとうございます。難しく感じたと思ったら、分からない所を日本語でも良いので調べてみるといいと思います。意外と、日本語で理解できてない事が多いのだとハッシュは自分で気づかされました。
ひとりでも多くの人にRemmeのセキュリティの概念を変える技術を知ってもらいたい、またトークンホルダーとして一緒にRemmeの成長を見守ってほしい、なにより多くの企業に情報漏洩やらハッキングなどとは無縁になって欲しいとハッシュは心から願っています。
