License

この文書及びTenyu基盤ソフトウェアのソースコード及びバイナリのライセンスはTenyuLicenseです。用途制限：本ライセンスはp2pソフトウェアまたは創作活動のプラットフォームを作成する目的ではない場合にのみ適用される。

リンク可。記事やコメントやツイートにおけるURL付き引用可。

概要

※現在ソフトウェア制作中

ソフトウェア制作、知識生産、その他オンラインゲームのプレイヤーや動画制作者等が成果物を有料化する事無く自由な相互利用を保ちながら幅広くネット上での活躍が収益化される状況を目指します。もしこの構想が実現するなら、このプロジェクトへの貢献によっても報酬が得られます。

Tenyuについて身近なたとえで説明すると

ステマを技術的に防止するプラットフォーム
就職や販売や寄付や投資といった行為を伴わずにソフトウェアや知識の生産活動を収益化できるプラットフォームです。さらに、参加者から金を回収するのではなく、参加者に稼がせるプラットフォームです（構想が実現した場合）。
地域通貨のネット版です。その通貨の分配・回収に独自のモデルを持ち、結果的にソフトウェアや知識生産活動の汎用的な収益化システムとして機能します。
従来多数のMMOがサービス終了ないし衰退してきましたが、持続可能なMMOのモデルを提案し、それがTenyuの独自通貨の回収モデルとなります。
誰がどんな貢献をしたかをフローネットワークを用いて記述します。それがTenyuの独自通貨の分配モデルとなります。
政治家がどう経済成長するのか環境問題をどうするのかなど議論している事がありますが、Tenyuはそのような問題への独自の回答を持ちます。財政問題を解消しうるほどの経済成長の可能性がありかつ環境負荷が限定的である経済構想です。ソフトウェアという新しい領域を適切なモデルで経済化し、経済成長の軸をソフトウェアやMMOに移す事による環境負荷の軽減。
アニメや漫画やゲーム等で海賊行為が良く問題になりますが、Tenyuはそのようなコンテンツを無料公開しつつ収益化するアイデアがあります。

※この文書では技術的な話が出てきますがプロジェクト概要を把握するだけなら飛ばして構いません。

構想ソフトウェア制作や知識生産活動を収益化するための汎用的なプラットフォームや、持続可能なMMOがあります。
革新的技術 ブロックチェーンを代替する独自のP2P技術による従来技術と比較して桁違いに高性能かつ堅牢な仮想通貨（もちろん通貨以外のデータも扱える）があります。
政治的主張 著作権やソフトウェア特許を作者権に変えるべきとか、環境負荷低減のために仮想経済を軸に経済成長しろという政治的主張があります。
世界的利益 世界の共用資産の増加や、環境負荷軽減等があります。
新資本モデル 私の考えでは、私がTenyuプロジェクトを通して提案している事はソフトウェアのための新たな資本モデルです。つまり、政府資本や民間資本等と同次元の新たな概念です。

全体を最大限単純化するとこんな感じです。

共同主体は相互評価フローネットワークやプレイヤー報酬で仮想通貨を人々に分配します。
連合型MMOによって仮想通貨の使途を作り人々から共同主体へ仮想通貨を回収します。連合型MMOにおける有料アイテムを仮想通貨で購入できて、支払われた仮想通貨は共同主体に回収されます。

Tenyuの構想はネット民が集まって何もないところに価値ある仮想通貨を作り出すというもので、集金行為ではなく価値生産と収益化の場を提供する事が目的です。

現在賛同者を増やすために説明を試行錯誤しています。分からなかったところをissuesかtwitterのDMで教えてください。レビュー記事歓迎。

twitter

回収ではなく与えるプロジェクト

Tenyuプロジェクトは参加者から集金する話ではなく、参加者にTenyuの連合型MMOで使用できる仮想通貨を与える話です。

集金する話ではないとは、法定通貨（日本円など）を徴収するような考えが一切ないという事です。参加者の間で仮想通貨と法定通貨を交換する事は可能ですが、それはこの構想が持続するのに必要な事では無いので構想外の話になります。

従来MMOがRMT市場を創出してきたことを考えてください。何もないところにネット民だけで換金性のある価値を創出できます。

簡易な説明

参加者に支払われる報酬はどこから出てくるか？高性能かつ堅牢な仮想通貨を実現するP2P技術を発明したので、オンラインゲームによってその仮想通貨に価値を持たせてアルゴリズム（仮想通貨分配）に従って作者に分配します。どうやって価値を持たせるか？多数のオンラインゲームでその仮想通貨を共通のゲーム内通貨として使う事によって価値を持たせます。オンラインゲームは仮想通貨に価値を持たせれるか？従来RMT市場が実現しオンラインゲームの通貨は法定通貨と交換されていました。オンラインゲームをどう作るか？素材を共有する仕組みがあり、素材やソースコードを公開する事が利益につながる仕組みがあるので、オンラインゲームの制作は徐々に簡単になります。最初にいくつかサンプルゲームを私が制作します。どういうアルゴリズムで仮想通貨を分配するか？相互評価フローネットワークのフロー計算によって分配します。そのソースコードは公開されます。相互評価フローネットワークでは人々の間の相互評価に基づいて仮想通貨の分配量が決定します。オンラインゲームはすぐに廃れないか？多数のオンラインゲームを連携させれます（連合型MMO)。1つのオンラインゲームが廃れるだけなら構想に支障はありません。

一般に創作的成果はその背後に複雑な貢献関係があり、フローネットワークを用いなければ正しく貢献関係を記述できません。創作的成果はある程度高度な独自の創作性が入っているとしても100％独自の成果である事はありません。本構想はフローネットワークを用いる事で複雑な貢献関係を正確に記述できて、それに基づいて仮想通貨を分配します。広く他者に自分の成果を提供し、無料で利用してもらい、参考にした他者の成果を相互評価フローネットワーク上で公正に記述し、共同主体から自動的に貢献に応じた報酬が各作者に与えられる。 Tenyuプロジェクトはそのための技術と構想があります。

License
概要
回収ではなく与えるプロジェクト
簡易な説明
関連した文書
目次
一般用語
- ソフトウェア用語
- MMO用語
問題
プロジェクトの経緯や状況や一般的側面
社会
独自用語ないし解釈
相互評価フローネットワーク
MMO構想
P2P技術
その他

一般用語

ソフトウェア用語

P2P

この文書で想定されるP2Pはネット上のP2Pで、「所有者が異なる多数のコンピューターが同じソフトウェアを実行するネットワーク」です。
https://ja.wikipedia.org/wiki/Peer_to_Peer

プラットフォーム

多様なアプリケーションが作成される土台（または環境）となるもの。パソコン、スマホ等多目的のシステムにおける全目的（便宜的）で共通の部分。
https://www.weblio.jp/content/%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0

アプリケーション

プラットフォーム上に作成される各目的毎の部分。
https://kotobank.jp/word/%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3-491

FOSS

http://e-words.jp/w/FOSS.html

MMO用語

問題

ソフトウェア及び知識生産の収益化構想とMMOとP2Pと社会の関係

これらの問題の本質的関係について。

P2Pとソフトウェア収益化構想（相互評価フローネットワーク）の関係
P2PとMMOの関係
P2Pと社会（口コミ）の関係
MMOと社会（環境負荷低減や経済成長）の関係
MMOとソフトウェア収益化構想の関係
社会（FOSS）とソフトウェア収益化構想（相互評価フローネットワーク）の関係

ソフトウェアや知識生産の問題

一般論としてソフトウェアはいくつかの問題を抱えていました。

パクり問題

社会全体においてどの程度パクりが横行しているか、その実態は不明です。いくらか悪質なパクりが有力な証拠と共に指摘されたケースもあります。一方で効率的に創作物を生産しようと思えばパクりは当然の帰結である事から相当悪質な状況が存在するだろうと私は予想しています。私は権威ある組織が全く悪質かつ意図的かつ組織的なパクり及び社会に対する欺瞞工作をした実例を1つ知っています。

ネットを検索してみればパクられたという主張はいくつかある。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1168578176
http://jin115.com/archives/52182928.html
https://techvisor.jp/blog/archives/3140
https://gigazine.net/news/20181204-tried-patent-after-job-interview/
http://blog.esuteru.com/archives/8307998.html
https://togetter.com/li/1190977
http://blog.esuteru.com/archives/7819934.html
https://mangaka-shigoto.com/category/trouble

パクり（剽窃、冒認）は芸術系の創作活動だけでなく知識生産でも横行しています。
http://senkensoi.net/topics/2015/04/171121
ソフトウェア特許問題

創作は時間がかかり計画的に生産できないので、利益を追求する企業の合理的帰結として、他社や個人の成果（ビジネスモデルもパクり対象になりうる）を模倣するのが有力です。パクる側はしばしば法的な侵害を問われないように表面的な部分だけ徹底的に置換します。そのためパクリが法的に立証される事はほとんどありません。そしてパクる側は創作活動にかかる時間を省略できます。
https://blog.inst-inc.com/doyouknowttplookslikebestwayforsuccess/
https://togetter.com/li/1466305
https://lexus.jp/magazine/20170517/20/exp_oyamada_02.html

広く模倣だと認識されていても権利侵害とみなされない場合もあります。例えばwowクローンのMMOはたくさんあり、いずれも広くwowクローンであると認識されていますが、権利侵害になりません。wowはその後商業的に成功したようですが、模倣作品に敗北する可能性もありました。ほとんどの作品は訴訟リスクを避けるため参考にした作品を明示しません。

他には、近年バトロワゲーム(PUBGやフォートナイト)が流行りましたが、個人制作のmodが起源のようです。 https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%88%E3%83%AB%E3%83%AD%E3%82%A4%E3%83%A4%E3%83%AB%E3%82%B2%E3%83%BC%E3%83%A0

『Minecraft』や『ARMA 2』のような大規模なオンラインサバイバルゲーム用のmodがジャンルの起源であり

現代社会は真面目に創作活動をするよりパクリ活動に専念する方が得という状況にあります（Tenyuプロジェクトはこの状況を変える構想です）。さらにパクりの横行は創作的成果があっても公開しない事に繋がります。特許は冒認出願が横行し、著作権は表面的置換によるパクりの隠蔽に弱くカバーできる範囲は限られます。現代社会はまだ創作活動を扱える社会に到達していません。

ところで、一般論として経済は法的保護及び環境整備があって初めて成立します。例えば、もし財産権が認められなければ窃盗が合法になり必然的に窃盗が横行し、金品を所有しておけなくなり、経済が成立しません。創作活動という現状酷く搾取されているものが法的に保護されたり信頼できるプラットフォームが出現すれば新たな経済を創出しうる可能性があります。

一方で、あらゆる知財等に適切な対価を支払っていたら今日の産業の大部分が成立しなかったという意見もあります。私は、そもそも世界的に共有可能な財産であるソフトウェアに関する発明をソフトウェア特許とライセンスという2者間の取引で経済化する事に無理があると思います。

まず創作者はTSAやリポジトリサービスを使うべきで、自分が真の作者であると証明できる状況を作るべきです。

解決策

存在日時証明
公開日時証明
健全なユーザープールの作成
相互評価フローネットワーク
創作活動を守る権利

生産性阻害問題

ソフトウェアは複製が容易である事から、単純に生産性を考えるとソースコードが公開されて世界の共用資産となっていくのが正しいように思いますが、世界の生産性に貢献しても売上0では続かないので、ソースコードの公開や成果物の自由な相互利用を達成するための経済システムが必要になります。

オンラインサービスも無料提供した方が良いものが多い。

解決策

抽象ノード概念
相互評価フローネットワーク
仮想通貨分配
創作活動を守る権利
無責任支払い

ソフトウェア収益化問題

世界の生産性のためには成果を共有すべきだが収益化する方法が乏しい
ソフトウェアを有料化するためにわざわざ一部機能を無効化するコードを入れる場合がある
世界中で使用されるプログラムやWEBサイトを作ってもほとんど収益化できない場合がある
アイデア等基礎的な貢献は収益化できない場合が多い
ライブラリ等裏側で貢献しているものが収益化されない（支援者との議論から）

ソフトウェア改修問題

他の人のソフトウェアに何かアイデアを思いついても自由に改修できない場合が多い。

ソフトウェア特許問題

ソフトウェア特許は多くの人によって問題が指摘されています。
https://japan.cnet.com/article/35015915/

私が考えるに、その根本的原因は、ソフトウェア特許の抽象度の高さとプログラムが様々な技術を組み合わせて作られる事からソフトウェア特許が多くのプロジェクトに影響を及ぼす事、特許制度が発明の背後にある貢献関係を正確に記述し得ない事等が原因としてあります。

もし全ての情報技術の発明が特許登録されたらソフトウェアの世界は破綻します。ほとんどまともにソフトウェアを書けなくなり変化のペースを保てません。現在そうなっていないのは特許を取得していない技術が多数あるから、または厳密に特許侵害が検出されていないからです。人々が完ぺきに法的に活動したら特許制度によってソフトウェアの世界は破綻します。現代文明はソフトウェアに関して構想レベルですら成立していないということです。

ハードウェアの研究、製品化、普及などは莫大な予算が必要です。しかしソフトウェアは個人でも基礎技術を発明できるし、製品化できるし、世界の共用資産として広く提供できます。その社会的性質の違いはあるべき経済モデルの違いになります。

他に、冒認出願が多い事、先行する基本特許に誰でも思いつくような小さなアイデアを加えた程度の特許など問題があります。重要な発明に挑むより誰かの基本的な発明に簡単なアイデアを加える事に集中するほうが経済的に合理的な行動である可能性があります。細かなアイデアで出願競争に勝利して特許を押さえてしまおうという行為は発明に取り組んでいるのではなくある種の法的闘争に取り組んでいるのであり、そこにおいて特許制度は発明を促進しておらずむしろ発明を阻害しています。正当な権利の主張、あるいは冒認出願などいずれの場合でも、一方で特許出願しなければ誰かに冒認出願されてしまうかもしれず、特許制度への参加が強制されている面があります。

Tenyuプロジェクトはソフトウェア特許問題を解決しうる構想を含んでいます。相互評価フローネットワークや、特に抽象ノードによる収益化がそれです。

プログラマーの不足問題

https://gigazine.net/news/20150708-micro-bit/

ネット上でのコード資産の共有によってプログラマーの不足は解決されます。

C/Sの問題

脆弱性

管理者による不正行為

口コミ系サイトでは評価を一定以上にするのにお金を払う必要があると言われています。真偽は別にして少なくともそのようなビジネスが可能な状況が存在します。
事実に基づく告発が信憑性無しとみなされて、あるいは圧力によって削除される場合があります。
MMOにおいてGMが一般プレイヤーでは到底入手できないアイテムをGM権限で作成し遊んでいる事があります。
ブログ等で記事が不当な理由で（多くの場合運営団体の利害関係から）削除される場合があります。
不正行為が行われてもそれを検証できません。

解決策

MMOの問題

MMOは根本的なモデルの問題がありました。以下に述べます。

コンテンツ消費問題

https://kultur2.blog.fc2.com/blog-entry-4277.html

従来の多くのMMOはコンテンツ消費型と呼ばれ、プレイヤー全体のレベルが高くなると低レベルのマップ、装備、スキル等が使用されなくなるという問題がありました。そしてレベルキャップの解放を繰り返しながらより難易度の高いダンジョンで強い装備がドロップするようになり、同時に既存のダンジョンや装備の価値が低下し、死にコンテンツを増加させました。コンテンツ消費型MMOは制作者が投入した労力（既存コンテンツ）が無駄になる事やクライアントソフトウェアの肥大化、ゲームの仕様が複雑になりすぎてプレイヤーの学習コストが高くなる等の問題があります。プレイヤーは死にコンテンツを回避する必要があります。意味のある、保守されているコンテンツのみを選択して効率よくキャラクターを育成する必要があります。そのためにゲームの仕様を学習する必要がありその学習コストが新規プレイヤーを遠ざけます。やがて開発者も全仕様を把握できなくなります。

コンテンツ消費型にならない持続可能なMMOのモデルとは？私はそのような問題領域を仮想経済と呼びます。

本構想の連合型MMOはコンテンツ消費型にならないモデルになっています。

エンドコンテンツ問題

上述した通りコンテンツ消費型は持続不可能で、良くエンドコンテンツが必要だと言われます。 MMORPGはプレイヤーに成長を感じさせる必要があります。エンドコンテンツは成長を感じさせつつ持続可能である必要があります。

従来どのようなエンドコンテンツがあったか。

PvPをさせる。しかしMMORPGでPvPをさせると装備差で決着がついてしまう。それが逆に装備を集めるモチベーションになる場合もあるかもしれませんが、良い装備がある人の方がゲーム内資産の蓄積ペースが速いので後発はずっと追いつけずPvPで負け続ける事になります。
ギルドメンバーの増員、成長、連携の成熟を楽しむ事。あるゲームはこのアイデアを実現していましたが、その膨れ上がった勢力で何をやるかがゲームに用意されていなかった。

Tenyuで新たに採用する構想

制作者になり自分のゲームを登録する。自ら新しいゲームを作る。これも一種の成長。連合型MMOだからそれが可能。
SNSを楽しむ。様々なオンラインゲームにおいて一貫して共通のアバターを用いる事でプレイイングが自己表現になる。ネトゲがvtuberに対応する。
全ゲームで共通の仮想通貨が使われるので、それを蓄積する。即ち新しいゲームにおいて有利（すぐに装備を買える）になるが、既存のゲームでは追いつかれる（装備がコモデティ化する）。

P2P技術の問題

従来のP2P技術は様々な問題がありました。

演算量証明受付時間問題

従来のP2P技術は四六時中演算量を注ぎ続けて消費電力を食っていました。さらに演算量を稼ぐ競争が生じました。

ハードウェアアクセラレーション問題

従来のP2P技術は演算量を稼ぐための専用のハードウェアを用意して、CPU以外のハードウェアで演算量を効率良く稼げてしまい一般ユーザーを出し抜けてしまう事で実際の多数派が演算量において多数派にならない恐れがありました。またハードウェアアクセラレーションの競争を発生させました。

更新性能問題

P2Pネットワークで共有されたDBの更新性能が低かったりしました。

ノード信用問題

演算量以外の信用ソースを持ちえないという問題がありました。これらの問題も解決されました。

プロジェクトの経緯や状況や一般的側面

Tenyu基盤ソフトウェア

Tenyuは本構想を実装した私が作成しているプログラムの名前です。Javaのアプリケーションで、P2P承認情報基盤です。 Tenyuは分散合意とプロセッサ証明に基づいた近傍評価及び同調処理という発明によって、高性能かつ堅牢な仮想通貨及びP2P承認情報基盤を実現します。さらに、その技術によって、本構想ではユーザーが全体運営者を選挙的プロセスによって選出する事が可能です。 Tenyuのあらゆる承認情報は堅牢性が保証され、過半数の参加者が健全である限り保存された承認情報は恣意的な改ざんを受けません。全体運営者や開発者ですら恣意的な改ざんが出来ません。ネットワークの大多数のノードが協調して改ざんしようとすればできますが、大多数のノードが悪意を持つ事は考えにくい。大勢の攻撃者が居れば一部のノードに一時的に不正な値を見せる事は可能ですが、過半数の参加者に不正な値を見せる事はできず、過半数の参加者の持つ値がネットワークに広まります。Tenyuの承認情報は完全な透明性があり、状態遷移が追跡可能で、誰でも検証できます。ネットワーク勃興から最新状態までの全状態遷移を再現できます。誰でもTenyuで共有された全ての情報が取得可能で、そこにユーザー一覧や各ユーザーのアイテム所有情報や仮想通貨残高やユーザー間の相互評価等重要な情報が全て置かれているので、誰もがそれらの情報と連携したサービスを開発できます。 TenyuはP2Pネットワークを通じて改竄困難な選挙を実施できて、各運営者の影響力の設定ができたり、アンケートが実施できて、全ユーザーによる意思決定が行えます。

プロジェクトの状況

ソフトウェアの状況
この独創的な話を理解してくれる人を増やすのが目下最大の難関
特にP2P技術に関して、私はセキュリティが成立していると主張していますが、一般論として脆弱性が無い事を証明する方法は無いので、誰か実力のある人にレビュー記事を書いてもらうしかありません。

このプロジェクトは「大勢の参加者が得られればこうなる」というような事を良く主張しますが、現状参加者はほとんどいません。

ソフトウェアの状況

※とりあえず読む必要ありません。

基盤ソフトウェアは一通りの基本設計に成功し、テスト環境でのP2P機能の実証を終えました。さらに後々のことを熟慮し設計を洗練しました。

今後レーティングゲームや常駐空間ゲームを作る必要がありますが、そのためにはVRMやモーションファイル（BVH等)を読み込む機能や各種3D系素材が必要になります。さらにjavaでVRMを読み込む場合PNGのデコードが遅い等問題があります。可能な限りクロスプラットフォームであるべきという点もあり高速化のアイデアが難しい。

私はとりあえず非常に簡単な2Dのサンプルゲームを作って誰もが構想を確認できる状況にしようと思っています。

他にDBに対して高度な検索を提供するグラフ検索に対応した管理ツールが必要ですがまだ作成されていません。

免責事項

本アプリの利用者は以下免責事項を承諾してください。本アプリの著作権等一切の権利は私（後述する「私」参照）にあります。本アプリを実行すると、他の利用者のコンピューターとの通信、ネットワークへの高い負荷、ストレージやメモリやCPUの使用、1日3回程度の高いCPU負荷、本アプリの自動的なオンラインアップデート、本アプリにユーザーが手動で入力した情報または自動的に取得される情報のP2Pネットワークでの共有が生じます。自動的に取得され共有される情報はタイムゾーン等およそ重大な個人情報ではなく利用者に損害を与えないと思われるものに限定され、ソースコードが公開されるので誰でもその詳細を調査できます。そのような情報は単に本構想を円滑に実行するために使用されます。例えばタイムゾーン情報はオンラインゲームにおいて誰とマッチングするかを決定する際に使用されます。本アプリを利用する上で発生したあらゆる損害に関して、私は一切の責任を負いません。本アプリはユーザー登録システムがあり、ユーザーはBANされる場合がありますが、BANによって生じた損害について私またはBANの決定を下した他のユーザーは一切責任を負いません。

プライバシーや動作等に関するポリシー

この項目で述べる事はポリシーであり、ポリシーを順守する努力は行われますが、契約や保証を意味しません。この文書で本アプリの目的が説明されますが、本アプリはそれら公称された目的のために必要な情報が取得され、必要な処理が行われます。ユーザーの損害となりうる情報公開その他ユーザーにとって損害となりうるあらゆる動作が生じないよう配慮して設計されます。取得された情報の大部分はP2Pネットワークで共有されます。ユーザーが手動で入力する情報と本アプリによって自動的に取得される情報があります。自動的に取得される情報は、グローバルIPアドレス、タイムゾーン、通信時の送信ポート、物理コア数、HDD容量及び残り容量、メモリ容量及び残り容量、使用OSやCPUの種類、現在日時など、本アプリが公称する目的のために必要な動作のための情報です。個人情報の不必要な収集は行われません。収拾された個人情報を販売するようなビジネスモデルや目的は本プロジェクトに存在していませんし、今後も存在しません。本アプリはwebapiを通じて同じコンピューター上で動作する任意の外部ツールに本アプリが管理する情報の大部分を提供します。

採用したソフトウェアの構成

programmingEnvironment.mdに私のソフトウェアに関する思想を書きました。それら思想からソフトウェアの構成を決定しました。

全Tenyu関連ソフトウェア

言語はJava
JDKはLiberica
バーチャルプラットフォーム

Tenyu基盤ソフトウェア

P2Pベースの特殊なアルゴリズムを実装する。性能やセキュリティ面で留意事項が多い
GUIから各種機能を利用できる。
jME3のjarが同梱される。各ゲームはjME3を同梱する必要が無い。
Tenyutalkというソフトウェアを同梱する。

Tenyutalk

P2Pベースの単純なシステム。分散処理の性能的な強みを最大限活かせる。
WWWを代替しうる基本設計を持つ。

登録されるオンラインゲーム

オンラインゲームは仮想通貨に価値を与える役割がある。オンラインゲーム内で使えるアイテムを仮想通貨で購入する。オンラインゲームをプレイすると仮想通貨が手に入る。
ゲームエンジンはjME3
バイナリ互換クロスプラットフォームであること。
基盤ソフトウェアから起動される。起動時にjME3などいくつかのjarがクラスパスに指定される。 jME3のバージョンを基盤ソフトウェア上で設定しておける。その設定に応じたバージョンのjME3がクラスパスに指定される。基盤ソフトウェアに同梱されているライブラリを使う場合、ゲーム側に同梱する必要が無い。特にjME3は230MB程度あり大きいので同梱しないこと。
Tenyu基盤ソフトウェアに登録された全素材を実行時に取得できる。素材を同梱する必要が無い。
全ゲーム共通の演出マネージャーがアセットでゲームを演出する。
アバターやボイスに関して、プレイヤーは自分で登録したものを使える。登録されない場合デフォルトのものが使われる。

ネット上で自由に配布される衛星作品

例えばフリゲや動画や配信等

管理ツール

Tenyu基盤ソフトウェアが持っている情報にグラフ検索を提供する。例えばユーザーAが紹介したユーザー一覧、さらにそれらユーザーが紹介したユーザー、それらユーザー全体のBANされた人数など。

基盤ソフトウェアのソースコードの公開

動作の透明性のため基盤ソフトウェアはソースコードが公開されます。

Tenyu基盤ソフトウェアを実行するリスク

※プロジェクトの概要を把握するだけなら読む必要無し。最大のリスクはIPアドレスとTenyu上のユーザーIDの対応関係が公開されることです。もともとTenyuに関係無くネット上での行動によってあなたのIPアドレスが知られてしまう可能性がありますが、IPアドレスが分かるとポートスキャンが可能で、あなたが実行しているP2Pソフトウェアが分かります。Tenyu基盤ソフトウェアもP2Pソフトウェアです。IPアドレスが分かるとあなたが実行しているTenyu基盤ソフトウェアにアクセスされ、あなたのTenyuにおけるユーザーIDが特定可能です。ユーザーIDが分かればそのプロフィール等が見れます。あなたのネット上での活動がIPアドレスを通じて紐付けられてしまうリスクが少し上がります。

Tenyuの仕様を考えるにあたりユーザーのIPアドレスが知られてしまう問題について解消する方法が見つからなかったので、むしろ利便性を選択し任意のユーザーの現在のIPアドレスが分かる仕様になっています。 ネットを使う時点で他人にIPアドレスを知られる事は回避しきれないので、知られても問題無いように対策しておく必要があります。対策はルータやPCのソフトウェアを最新にしておく、アンチウイルスソフトを使用する、Torブラウザを使用する、ISPと複数契約する等です。

あと強いて言えば、P2PソフトウェアのためにPCをつけっぱなしにする傾向が強まると雷によってPCが被害を受けやすい。特にLanケーブルは雷対策がされていない事が多い。

私

私は個人のプログラマーで、長年オンラインゲームのプレイヤーで、ソフトウェア収益化問題や情報技術やMMOのゲームデザイン等について長年考察してきました。

経緯

twitter https://twitter.com/lifeinwild

メールアドレス exceptiontenyu@gmail.com satoji@protonmail.com lifeinwild1@gmail.com

RSA 4096 publicKey BASE64 PcKey:MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAsr3dxpS/V6zzCl16xVKwTUHpGlGE8IpFWcFdMkB90YyQyfoRwQm1dlSD8Rn6u3+OvfmBPoz9ppa+H4Zu9G9E9m0xYmnsIYakIMIboUt1qd95JNpqxzImTkWv0b2gInnwFeBp0LN/keRHicrBuUfVq98qwitcQq1OYQUQuJyeMXmmDxkvv8ug3fXizw/zDVKJ8M7nrsfjSnFwfi5egitd9eX3/KqQf5UGn7NqWbXFUPQwQ7MLQ9K8dfOF9xweWrrMEC57WZECxI82CTOprmvNruNh7FOLbqA0RpIdC1SRj6WgsOqveSXv/c+kU0R6zs7FVDg2X75n+fFOCLybEg0v2auBsiteQzdPoQvdLoJWvXKZ3ofCF0L3Gv8fhiR/3w6MLWHYYqsYkzdwmSjUS1SiPjCSrxonyId988o6Y82KwxiuEp50hvroJ0raEV9LhkfimkGTbSVegyag/avMksRvFM2aRlkncksTcCywNyfzMB8g73WoewTFO3tZ8V8JZB4csrot1jNfmQCIsYA6a0GgdQk9z7dhB+0zVS7kuXO+Djh6lpP5BM2uxByA0GBh1HYchuuEHasITRwqqzGozDFx2ScobegMQx4hObWv81O3rQdDhbEvG9h8jFZQB4yMQYjLQQaRhuTiq2Rr/critB/TmjhMIaDsemSkgkm3tWbpHAUCAwEAAQ==

MobileKey:MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEApIEDa624qLZcsZKRbAND9fgRylL2uvvm/OFafB420BXp270Doj1avizKheVJgeGz3dbV74ML3sTsLa6U46rtO8CTTeWec5o9OXNhRACdiqYMAx9uzifCvFe/VOSwwjp48bcCn4DrpvwVbD1ipbPo3Mt6ym7mX6491uonKkad6b9nlRAueesjP7C+yha8qOXzWQu3ibgRvEHj7pWXYrPUoP6k/A2QANkcDanzPA81gNCQLeU9JgyBIOjVVuW1++8xNTD+HVzww+5pF3lyFfAiCNjjMDAfuiHVExogF014oX59s9pvcE/8HWiAv1xyYaEeJ/8Li8189kHL9A2y7V91SErpHWvXr31OtymTrBH97eczLh8152MV2STDZRm73Uu9WtpGB6JyCA/0Tsl6C25em3B8Pb020ULEa7H+86PXjuifICqP4hzDLYPbbCXh3/lmAtibyRnjaA3I32wfKfCiN57i9X8SBjG1en9WqWxDSLo0BsWLMJjf3dP1PalBL17/a5EF5FfARL5/wIRkl58geLgvtGz0oKaoz/RvMmyuTD7cqZ1J03GZGVswlPfTMuDOSu1na3cKRYPpAyQcHYd/y7y1jP4KWt+fNE22gJUfYzr/aF4Eua+UDdln1Tq1B2BZycSwsy4NjMIJMxaGTI1EJUwykCiVYi+uEBdOWT74zEkCAwEAAQ==

OfflineKey:MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAiUDRqf9GiC0rX6k2BxknD1qMBJdH8PfeCr5nnprn+PYqUwb1lAUA2OOTB9gLsfDsFpdfwF6B2Sa8r+f17tfNPSzUwMwi9Gj3tiYoaKdo+Y8zx1iHDvcCzgMw6I8gz8SYXZmgPCNEnkX0KbWN/gNBDP9DfYZkznSM3Mq6cIcWcRvn/9GUIB0E5WKqKm4axUJbyzuh653W0H2g3BnnQkknwGx2Dl4znDDLZ8pLwjB7Irt+Kn5r/pR3kUXfoxbkeIe663a6DeSV2GFnghSNgTtzVmyj5CDTVwMdVXYdenBnmtIgIgobqzA4a+890B3eecJ5NOIOn9qh6cY7p8il0aG0M7CT9XsA9Ld76FYqAfMS2c86WkI8d4kSswU5WdaXJ6FND2duUXJBeOJbw8XhqWO5I/tW9Y33iXTXpiF3cuJbCn7XF8F4cHFAS7nMEI+rlc8ADjRx+OCk1qJPNpZyzvcJpfZP2gTmTWbEKt8Znc2+Wt7nIY/Hk4aRNfMbF5K7WPz1knR4GR9sUHL5t+OPZjJOqvQGrgMJ3v/f5j54cpecEJbpHrx83cxS3LQIWROZa+5lgjOk1T0hD+dUYyTeoJj3zfZHIdgKpslO7xraZiUcEG8gETYW9FRGQ+jVBvAZpuqxlchMAYOYFxW4LV0wYEZME1OpFzHWTjln6G1VwnXADg0CAwEAAQ==

他の公開鍵は長くなるので別ファイルに PublicKeys.txt

プロジェクトの経緯

2012～2015年頃相互評価フローネットワークを、2015年頃分散合意とプロセッサ証明とその相補的仕組みを、2017年頃そのP2P技術を完成させる最後のアイデアである近傍の近傍数の証明的取得を、さらにオンラインゲーム主軸モデルを発明、構想しました。

本構想やP2P技術の発明者が私であることは、2018年1月のTSA、2018年5月の特許の電子出願によって証明できます。特許出願を除けば、私がこの発明について初めて他者に伝えたのは2018年7月です。私はソフトウェア特許に疑問を持っていますが、発明者であることを証明するために出願しました。

https://bitbucket.org/tenyuproject/tenyu/commits/all 2018年7-9月にかけて、オンラインゲームの古い知り合い2名にこの限定公開プロジェクトの内容を見せました。一旦限定公開の段階を作り限られた人に見てもらいフィードバックをもらおうと考えたからです。

さらに、私が基盤ソフトウェアを完成させるタイミングでゲームが完成する方がプロジェクトが早く進むと思い、ネット上でゲーム制作ができそうな人を探し1名に協力を求め、当初好意的な反応で協力してくれるとの事でしたが、その人は結局何も作らずこのプロジェクトを離れました。その人が作ったものはゲームエンジンが自動的に作成するファイルを除けば、数行の機能しないコードだけだと思います。さらにゲームの素材を作れる人を探し1名に協力を求めましたが、協力が得られませんでした。そして、結局私は一人で全て制作する事になりました。

2019-9-19に限定公開を辞める事にしたのでgithubに移動した。 https://github.com/lifeinwild/tenyu/commit/294c15265b6f14d1d10d49fa1b99b0c0f15f55a1

想定される参加者

私は創作活動による経済を実現するためにその他の全ての問題を無視して協力できます。想定される参加者は創作活動による経済というこのプロジェクトの主旨に賛同する人全てです。

Tenyuプロジェクトに影響を与えた創作的成果

PHI β-Yak-38
https://ja.wikipedia.org/wiki/Phantasmal_Island
15歳頃プレイしました。管理者が異なる多数のサーバの連合型MMOはTenyuのオンラインゲームを連携させる構想と類似するものです。
でんし共産制社会いんみ～
http://www5b.biglobe.ne.jp/~shu-sato/dc.htm
16歳頃このブログを読み、現在重視されているアイデアや価値観が限界を迎える事、軽視されているアイデアや価値観が未来において少し形を変えてむしろ重要になる可能性があるという信念、断片的な理由から将来の経済システムの輪郭を描き出そうとする知的姿勢に影響を受けました。
フローネットワークのSNSへの適用。このアイデアは昔情報技術の研究者がWEB上で紹介していました。どこかの水道か土木関係の会社に勤めてフローネットワークの研究をしている人だったとおぼろげに記憶していますが、今探してみてもURLは見つかりませんでした。「そのような会社で情報技術の研究ができているのはフローネットワークが人間関係の記述に使える可能性があるという事を会社の偉い人たちに説明すると受けが良いから」というようなことを書いていたと思います。
ビットコイン satoshi nakamoto
演算量証明という概念は極めて重要で、TenyuのP2P技術はそれを応用したものです。
公開鍵暗号、RSA
https://en.wikipedia.org/wiki/Public-key_cryptography

公開鍵暗号と演算量証明、さらにTenyuの分散合意という技術によって世界的な改竄困難な電子投票が技術的に可能になります。他にP2Pネットワーク上でのDBの堅牢な共有が可能になります。

必要スペック

このソフトウェアは常駐起動させておく想定なので、ブラウザ等他のソフトウェアと同時に動作させれるスペックを必要スペックに設定しました。ゲームのプログラムや素材ファイルをDLするので必要なストレージ容量が大きくなります。最も懸念されるのは回線とストレージです。

cpu 4core+
network ↑↓20Mbps+
mem 8GB+
ssd 80GB+

推奨スペック

cpu 12core+
network ↑↓300Mbps+
mem 32GB+
nvme ssd 4TB+

Tenyuの実行環境

Tenyuの基盤ソフトウェアはJava 8を使用します。登録されるゲームなど関連ソフトウェアも基本的にJava8を想定します。 Java9から自己完結型パッケージが推奨されるようになったと思いますが、 Tenyuプロジェクトは参加者が自作ゲームを登録できるようになっていて、いちいち自己完結型パッケージが登録されると同梱されるJREによってストレージを圧迫します。しかも自己完結型にするとバイナリ互換のクロスプラットフォーム性を失います。各環境のバイナリを用意する方法はファイルサイズの増加が無視できません。自己完結型は同梱されたJREがバージョンアップされない可能性が高いという問題もあります。登録されるゲームはJREを同梱する必要が無く、さらに素材や一部ライブラリも基盤ソフトウェアがクラスパスを与えるので、ファイルサイズが非常に小さくなります。

その他JDKがどうあるべきかということをprogrammingEnvironment.mdに書いてあります。私はモジュール構想にも自己完結型パッケージにも否定的です。

Javaでゲームを作る

昔JavaはGCのラグのせいでゲームに向いていませんでした。しかしGCが改善されたので再評価されるべきです。（特にZGC） GCのラグは以下のオプションで十分にラグを短くできると思います。 -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

ゲームはOSの移行を躊躇わせる主な要因ですが、Javaのゲームならその問題はありません。もし今後Windowsから他OSへの大規模な移行が起きるとWindowsアプリケーションは実行されなくなります。Javaならそのような変化に強い。ソフトウェアはプラットフォームの淘汰移行という余計なリスクを負わなくて済みます。

LLVMベースのJDKはC++並の性能を持ちます。とはいえLLVMベースのJDKはまだ普及していません。

基本的にJavaの性能はC++より15%低い程度で大きな問題はありません。

開発効率や保守性はC++よりJavaの方が優れています。
https://www.lanl.gov/projects/CartaBlanca/webdocs/PhippsPaperOnJavaEfficiency.pdf

The data is too noisy to be certain that Java is twice as productive as C++, but it is certainly better この記事はかなり古く、恐らくこの時点より現在の方が差は広がっています。

一般論としてPC用オンラインゲームのクライアントはたびたび落ちます。昔からこの分野で安定性は不十分です。Javaのゲームならより安定するかもしれません。JavaはC++よりバグが少ないようです。
https://www.lanl.gov/projects/CartaBlanca/webdocs/PhippsPaperOnJavaEfficiency.pdf

The experiment suggests that aC++ program will have three times as many bugs as acomparable Java program.
https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
Table 6: Some languages induce fewer defects than other languages.
C++ 0.23 Java −0.01

起動時間を除けば、JITはAOTコンパイルより優れています。Tenyuの構想では基盤ソフトウェアのアプレットとして各ゲームが動作するので起動時間はむしろC++プログラムより高速になるはずです。

Javaは使用者が多く創発的現象に期待するなら妥当な選択です。

TenyuのP2P技術の概要

Tenyuは高性能な情報更新技術である準P2P型(一斉更新)と低性能だが純粋に分散的な純粋P2P型(選挙または同調処理)を使い分けて耐障害性と性能を両立しています。いずれもP2Pネットワークで共有されている情報を更新できて、一度P2Pネットワークで共有された情報は喪失したり改ざんされません。情報の作成過程も改ざん困難で誰のどんなメッセージによるものかを証明可能です。

しかし準P2P型はシングルポイントがあり、そこに障害が発生している間、情報の更新が停止します。シングルポイントと言っても実際には多重化されていて耐障害性を強化できます。もしインターネットがブロードキャストか検索型マルチキャストを一般に提供するなら一斉更新は純粋P2P型が実装できてメッセージ受付サーバは不要になります。Tenyuが準P2P型を採用している理由はメッセージ拡散の効率的な方法が無いからです。恐らく従来のほとんどのP2Pソフトウェアがその問題に悩み、仮想通貨系ソフトウェアでは効率が悪いを無理やり使っていたと思います。準P2P型は例えばゲームに関する情報の更新やユーザー登録や仮想通貨の送金処理などに使われているので、メッセージ受付サーバに障害が発生するとそのような機能が動作しなくなります。とはいえ既存のデータが壊れる事はありません。

純粋P2P型は純粋に分散的で最高の耐障害性があります。 そこで、純粋P2P型は全体運営者の選出などこの構想の最も基礎となる機能に用いています。 純粋P2P型による投票はP2Pネットワークのノード数に比例して改ざん困難になります。

メッセージ受付サーバが停止して復旧しない場合、全体運営者の選出に伴い自動的に全体運営者がメッセージ受付サーバの候補に追加されるので再開可能です。

同調処理は、P2Pネットワークでは各ノードは任意のタイミングでオフラインになったりオンラインになったりするので、オンラインになった時にそのノードの情報が古い可能性があり、最新情報を持っているノードに同調する必要があります。同調処理は純粋P2P型で行われます。

TenyuはP2P領域で普遍的な技術を複数持ち、要件に応じて使い分けています。

ソフトウェアを更新する役割は作者である私に依存しています。もしソフトウェアを更新する人を動的に決定すると（全体運営者など選挙で選ばれる人物に任せると）、動的に決定される人物が参加者のPCにソフトウェアをインストールさせる権利を持つ事になり、極めてハイリスクになります。そこで作者である私と全体運営者双方の署名が必要という仕様になっています。

Tenyuの性能

最低限、「活発なユーザーで同時接続100万人」をクリアできるように設計してあります。大雑把ですが、今後のコンピューターの性能向上によってこの10倍程度可能になると思います。大雑把ですが、ユーザー全体のほんの一部しか活発に活動しないので、全体のユーザー数はさらに5倍程度可能と思っています。大雑把ですが、つまり今後のコンピューターの性能向上を見込んだとしてユーザー数5000万人程度が可能だろうと思っています。実際のp2pネットワークにおける性能実験はできておらず、私の想像力と簡易なテストケースによって控えめに見てこの程度の性能があると考えているだけです。

※この項目は重要でないので飛ばしてください。 1ノードの簡単なベンチマークを取りました。これはCPUやストレージ等のボトルネックを明らかにします。一般論としてベンチマークは難しいものです。条件によって数値が変わります。この項目で書かれている数値はかなり控えめな数値です。以下の数値は2009年頃のPCを想定しています。 DBのテストではUserの更新が3000件/sを超えました。Userの更新は他のデータの更新と比べて重い処理です。他オブジェクトの作成処理は3250件/sを超えましたが、内部的には1件あたり2オブジェクトを作成しているので6500件/sとも見れます。Tenyuのメッセージ処理は2分のうち1分をメッセージ反映に回す事、1メッセージあたり平均2オブジェクトを操作すると仮定して、DBの限界性能は2分間に18万メッセージ程度と予想しています。しかしP2Pアプリは同時実行されている他のアプリの影響で性能が劣化する可能性があります。さらに、電子署名の検証もボトルネックになりえます。電子署名のボトルネックはマルチコア化が進展すると自然に解消されるような設計になっています。もし12コアが標準になったら、デフォルト設定でそのうち最大9コアをTenyuは使用し、電子署名のスループットは約9倍になります。現状4コア想定でそのうち最大1コアを使用するので、3-6万件程度が限界とみています。実際、Tenyuのメッセージ処理ペースは現状2分間あたり3万件に設定されています。その設定は全体運営者によって随時変更できます。可能なP2Pネットワークの最大規模はノード数1億を想定しています。参加者の標準的な回線やストレージ性能等が改善される事でメッセージ処理ペース及び最大ノード数が増えます。

Tenyuのメッセージ処理ペースは参加ノードの性能に依存します。現在想定している性能はおおよそ10年前のPCで、以下の性能です。

SSD write 20k iops, read 45k iops
CPU Passmark 4800程度 https://www.cpubenchmark.net/
Network 近所との通信で実測100Mbps なおメッセージ処理ペースがノードの性能に依存するというTenyuのP2P技術の特性は重要です。その特性は従来の仮想通貨技術にありませんでした。ITにおいてストレージ、CPU、ネットワークはいずれも急速に性能を向上させているので、Tenyuのメッセージ処理ペースは今後大幅に改善される可能性があります。例えばSSDは20-45k IOPSを想定していますが、近年のSSDはこの数倍の性能があり、将来的にNVMeというさらに高性能なSSDが普及する可能性もあります。回線も現在主流なのは100-300Mbpsですが、10Gbpsが販売されています。今後状況次第でTenyuのメッセージ処理ペースは10倍程度向上する可能性があります。ただし、一部のノードだけが高速化してもほとんど意味はありません。P2Pネットワークの多数派の性能が向上する事でメッセージ処理ペースが向上します。

30万IOPS以上のストレージが普及すれば2分間に120万メッセージ程度までストレージはボトルネックにならなくなります。

ネットワークが近所との通信で実測840Mbpsが標準になったら、ノード数1億として100万件程度までボトルネックにならなくなります。処理ペースを60万件程度に絞れば可能なノード数を100億以上にできます。 Tenyuでボトルネックになる通信処理は全く同じデータを多数のノードに送るブロードキャストであり、無線等でそれを高速化する方法が確立すればネットワークはボトルネックにならなくなります。

メッセージ反映処理は2分に1回行われ、その間に送信されたメッセージがまとめて反映されます。2分に1回という周期はプログラムに設定されていてコンピューターや回線の性能に依存しません。つまりTenyuへメッセージを反映するのは基本的にレイテンシとして0-4分程度かかります。

Tenyuはproof of workの時間が1日10分程度で済みます。ビットコイン系は24時間フル稼働する必要があります。フルロードの時間が144分の1です。とはいえ消費電力の差を考えるのは難しいです。フルロードの時間が144分の1でも、アイドル時も消費電力があります。しかしPCが起動している時間の全てがP2Pソフトウェアの責任とはいえません。WEBブラウザ等他のアプリを使うために起動しているのかもしれません。とはいえ、Tenyuは従来の仮想通貨ソフトよりも大幅に省電力であることは間違いありません。 TenyuはGPU等アクセラレータを大量に使った計算競争が必要無いので、そういった事が起こりえないという消費電力上のメリットがあります。分散合意とプロセッサ証明はちょうどブロックチェーンを代替する技術です。ブロックチェーンの代表的ソフトウェアであるビットコインは7取引/秒と言われています。Tenyuはビットコイン系と比べてメッセージのスループットが数十倍から数千倍程度期待でき、消費電力で大幅な優位性があります。

仮想通貨の流れ

仮想通貨分配

相互評価フローネットワークでフロー計算ができますが、フローに応じて仮想通貨が分配されます。分配元は共同主体であり、共同主体の仮想通貨残高の一定割合が定期的（1日1回など）に分配されます。誰にいくら分配するかが相互評価フローネットワーク上のエッジで決まりますが、エッジは大勢のユーザーによって作成されます。

プレイヤー報酬

プレイヤーはレーティングゲームでの成績に応じてそのゲームにおけるレーティングが計算されます。そのゲームへの仮想通貨分配の一部がプレイヤーにレーティングと試合数に応じて分配されます。

多数のゲームが登録されますが、それらゲームは相互評価フローネットワーク上にノードを持ち、ゲームのノードに到達したフローでそのゲームにおける報酬総額が変動します。つまりアイテムが良く売れるゲームほど分配額が増えます。あるゲームが獲得した報酬全体の一部がプレイヤー報酬になりますが、その比率は全体運営者が決定します。

各ゲームの運営者は報酬が支払われる最低レーティングと最低試合数を設定できます。不正プレイヤーはBANされるまでに最低レーティングと最低試合数を超えなければ報酬が得られません。

選挙的プロセスで決定できる情報

各全体運営者の権限割合の設定
アンケートの結果
新規通貨発行量

紹介制ユーザー登録

TenyuのユーザーDBは紹介制で、BANされた人が再度ユーザー登録して不正行為を繰り返すようなことをすると、繰り返しそのユーザーを紹介している人もBANされます。

アンケート機能

2種類のアンケート機能が提供される予定です。片方は分散合意を用いた基礎機能であり、もう片方はユーザーベースの簡易なものです。

社会

創作活動を守る権利

創作活動に対する侵害事例を見渡した時、そして相互評価フローネットワークとオンラインゲーム主軸モデルによる収益化を構想した時、作者権とプロジェクト権があればほぼ全ての悪質な侵害を否定しつつ創作活動による経済を構想できます。

作者権

創作的成果について、その作者や貢献者は他者にその立場を偽られない権利がある。

作者権は誰が作者であるかという事実とその成果の創作性の高さを成立要件とします。私がこの概念を主張する理由は、著作権は制限が大きすぎると考えているからです。作者権は相互評価フローネットワークとオンラインゲーム主軸モデルを前提とした場合に初めて妥当となる権利です。TenyuLicenseは著作権を作者権に近づけるように書かれたものです。

作者権は単純かつ最小の保護であり、著作権やソフトウェア特許などと異なり他者が自分の創作物を利用することを排除する意味合いが無く、創作の自由と競合しないので、より創発的です。そして、Tenyuプロジェクトは作者の経済的利益と創作の自由を両立する構想があります。創作物の自由な利用を促しつつ作者が妥当な報酬を獲得できるという構想です。もしその構想が成立するなら、それによって作者権程度の主張で十分に作者の経済的利益は達成されるから著作権やソフトウェア特許のような他者の利用を排除する権利を主張する必要が無いという考えが背景にあります。

作者権と著作者人格権はかなり似ていますが、その違いは作者権はあらゆる創作的成果を対象とし著作物の定義に影響されない事です。作者権は発明やアイデアも対象とします。相互評価フローネットワークが実現される前提で考えた場合、簡単に他者に報酬を与えれる事から貢献関係の記述について人々の善良さに任せやすい事があり、背後の貢献関係まで記述されやすいのでアイデア等の根本的な貢献も対象にしやすいから著作物より広い範囲を扱うのが合理的です。

従来の著作権やソフトウェア特許は世界の生産性を少なくとも部分的に阻害していました。他人の創作的成果を自由に利用できなかったからです。しかし作者権が主張する事は誰が作者または貢献者であるかを明示するという事だけであり部分的な阻害すらありません。

貢献者は共同作業をしたメンバーだけを指すのではありません。多くの場合創作物は完全な独創ではなく他者の創作物を参考にした部分があり、参考にした他者の創作物を明示する事で自分が努力した部分を示す必要があります。 自分の創作物だと言える程度の独自の創作性が入っていたとしても参考にした創作物を明示する必要があります。

作者権は創作者のための公正な世界を作るために必要です。それが実現されると創作者は長期的な取り組みがしやすくなり、創作者が互いを信用し創発的現象が起きやすくなります。悪質なパクリが横行すると創作者は相互に警戒します。

なおこの作者権の定義は作者や貢献者が望むなら匿名である事が可能です。完全な匿名かHNか実名かは作者側が決めれます。

パクリ、盗用、剽窃、冒認等の概念について。他者の成果を参考にする事は正常な創作活動の一部ですが、悪質とみなされる場合もあります。その境界はどう決まるか？それは社会を騙したか、不当な評価を得たか、誰かが得られるはずの評価を失わせたかで決まると思います。創作物を公開する場合不当な評価を獲得しないよう参考にした創作物を明示すべきです。それで同時に貢献者が正当な評価を獲得する事にも繋がります。ただし標準化した知識やソフトウェアはあえて言及しなくてもいい場合があると思います。作者権はいわゆる悪質なパクリを否定します。私が考えるあるべき創作物の相互利用ルールはTenyuLicenseに定義されます。

例えば、まとめサイトが他のサイトの掲示板のログを勝手にコピーしている事は悪質なパクリか？まとめサイトはどこから情報を引用してきたか明示しているし、どのような活動をしているのか社会に誤解させていません。ですから、他の面で問題が問われる可能性があるとしても作者権の観点からすれば、悪質なパクリではありません。それが何であるかについて社会が騙されていない事は悪質である事を強力に防止します。

作者権は簡単に言えば「（創作的成果について）社会を騙してはいけない」という事です。

創作者は他者が得るべき評価を損なわせないよう注意する必要があり、そのため参考にした創作物や自分の活動内容を明示する必要があります。自分の成果を証明する事も重要で、TSAやリポジトリサービスの投稿日時等が役立ちます。

創作活動による経済が実現されるには「真の作者及び貢献者が捕捉されるべき」とする道徳観を人々が持つ必要があります。

私が著作権の代替として作者権が十分だと考えれているのは１つ特殊な判断が背景にあるからです。まず、著作権が無ければ例えば映画等が著作権者に無断でネット上にアップロードされてしまいます。作者権は作者を捕捉させるだけなのでそのような行為を止めれません。では著作権が無くなり作者権だけになった世界で映画のようなコンテンツはどうすればいいか？オンラインゲーム主軸モデルというアイデアによって、もはやそのような取得を本質としたコンテンツは常にオンラインゲームの衛星作品として作成されるべきだ、と考えます。映画のような娯楽作品はその形態について必須要件がほとんど存在しないので、ネット時代に適合する形態に変われるだろうということです。これによって著作権侵害の調査や訴訟のための社会的コスト（ITの進歩と普及に伴い増加する）が無くなります。他に抽象ノードを使えば（ソフトウェアの世界で公益性が高いものなら）衛星作品でなくとも収益化可能です。他にドネーションは仮想通貨の送金機能がある時点で当然可能です。

他に抽象ノードやドネーションウェア（寄付による活動継続）のような収益化方法も考えられます。寄付はTenyuプロジェクトとして特段の構想があるわけではありませんが、送金機能があるので実現可能です。これらから著作権やソフトウェア特許を作者権で代替できると考えています。

作者権に関係する人権や憲法の条文

世界人権宣言第二十七条
国際人権規約A十五条一C　
憲法三章十三条　意味が広く大抵の事が該当する。
世界人権宣言第一条　意味が広く大抵の事が該当する。

著作者人格権は財産権か

著作者人格権（著作権法５９条により譲渡不可）は著作権に属するとされ、著作権は財産権に属するとされているが、財産権は少なくとも経済的価値を持つ対象でなければ認められないのではないか？そして著作者人格権自体は経済的価値が無いのではないか？

まず譲渡不可であることは交換価値が無い事を意味する。では著作者人格権はそれ自体が経済的に役立つか？

作者の創作意欲（ないし著作者人格権によって守られる作者の精神）は当人にとっては重要なものだろうが、経済的に役立つと限らない。創作活動は内発的動機で行うものであり、しばしば経済的利益と結びつかない事から。

交換価値が無くそれ自体の（経済上の）使用価値もないなら、他にどんな経済的価値があるか？

結論として、著作者人格権は財産権ではない。著作者人格権は世界人権宣言第二十七条や憲法第十三条や国際人権規約A十五条の「精神的～利益が保護される」で根拠づけられるべきで、財産権（世界人権宣言十七条）に属しません。

そうすると財産権＞著作権＞著作者人格権という説明の仕方が疑問に思えてくる。著作者人格権は財産権から根拠づけられる必要が無い根本的な権利です。

なぜ社会を騙してはいけないか

社会に偽の情報が多いと様々な人において判断難易度が上昇したり社会的認識の是正コスト（訴訟等）が上昇したりそのコストを回避するため消極的態度が増加するから。

逆に言えば、一人一人が社会的認識を正しく保全しようとしていれば社会の隅々に人の目が届いているので社会を騙すのは誰にとっても難しくなり、一人一人の警戒コストの低下や社会的認識の是正コストの低下があり、協力的態度が増加する。

社会的認識の保全を義務ないし道徳として捉えれる可能性があります。

プロジェクト権

プロジェクトの主導者はプロジェクトをコントロールする権利を持つ。

プロジェクトは計画を作り実行する活動です。

作者権だけあっても創作活動を守る事はできません。例えば非公開のプロジェクトに対して誰かが何らかの手段で内部情報を入手し流出させて、しかし誰が作者であるかを公正に述べさえすれば作者権侵害にならないからです。そこでプロジェクトを守る権利が必要です。

プロジェクトに対する侵害としては内部情報の流出、アカウントの乗っ取り、騙り、ねつ造、デマ、誤報等があります。

誤報やデマによる創作活動への侵害事例は例えばこの事件があります。
ドラえもん最終話同人誌問題

第三者によってWeb上に無断で公開された際には、作者・サークル名の記載された表紙や裏表紙は省かれ、本編のみであったことが後に誤解を呼ぶ事となった。

それが正史の最終話であるという情報はデマです。私の解釈ではこの事件の被害者はドラえもん公式とこの二次創作の作者両方で、加害者はこれが二次創作であるという情報を削除して広めた人達です。私が思うあるべき創作活動のルールにおいては、間違った紹介の仕方をした事と実際に多くの人が騙された事が問題であり、二次創作自体は否定されません。

人権

人権や憲法３章のような極力単純化された個人の権利を人々に流布する行為は、人々を社会の監視者として文明的問題を検出させる意味を持ちます。検出された問題を解決していった結果として公衆の環境的財産が達成されます。

人権は世界標準で憲法は国毎です。

ほとんどの人は法的に合理的な行動を取りません。犯罪被害にあっても社会的に抗議しません。裁判の労力や立証の難しさもあるものの、法律知識が不十分である事もあります。
そのため社会にどれくらいの数の深刻な犯罪被害があるのか知る方法がありません。しかし人権という最小化された論理を人々に広めると、犯罪被害者はそれが社会的な理不尽に当たると気付ける可能性が高まります。

人権はよく権力を制限するものと言われますが私はその考えを否定しました。権力を制限するのは民主主義または反乱の可能性です。もし民主主義や反乱の可能性が無く人権や憲法があるだけなら権力者はそれを無視できます。人権や憲法が人々に浸透し人々の意見が影響を受けた結果として、民主主義を通じて権力が人権や憲法によって制限されているように見えるだけです。

人権は人々が普遍的に元々持っている精神を記述したものだと言われる場合もありますが私はその考えを否定しました。人類史を見ても人々の言動を見ても、単に、とてもそうは思えません。しかし環境的財産を認識する知能は過半数の人に存在すると思います。つまり人権はこの時代でどんな精神を人々に普遍的に持たせると世界の環境的財産の最大化に適うかを追求した結果であるように思います。

人権や憲法３章は権力側でも国民側でもなく環境的財産の側です。

そして私は作者権やプロジェクト権を人権に加えるべきと主張します。人権は世界的ですが、私が世界的な事を主張するのは、ソフトウェアはネットを通じて世界的に広まるのでソフトウェアのための経済を構想すると人権の修正に思い至るからです。私はソフトウェアの収益化問題を考える中で人権の修正というアイデアが必要であることに気付きました。ソフトウェアや知識生産に関する（P2Pプラットフォームを前提とした）権利が流布されそれによる環境的財産が作られる事でソフトウェアを収益化する経済が可能になります。この考えはソフトウェアだけでなく知識生産全般に共通です。

ネット時代になり個人のソフトウェア制作や発明が可能になり、ソフトウェアの経済を作る必要があり、それを支えるための基本的権利を定義する必要があります。作者権はソフトウェア特許や著作権より単純かつ創発的です。

TenyuLicenseの概要

TenyuLicenseは相互評価フローネットワークを通じた仮想通貨分配による報酬に期待する事で他者が利用しやすい条件で著作物の使用許可を与えるものです。

例えばTenyuLicenseは著作物の利用者に相互評価フローネットワーク上で公正なエッジ作成を行う事を要求します。ライセンスに定義されている公開鍵の宣言はURL証明コードで十分です。

TenyuLicenseでは用途制限を記述できます。用途制限を記述する事でTenyuLicenseの著作物の作者は随時その著作物の用途を制限できます。例えば自分が作成したキャラクターのモデルに愛着を持っている場合アダルト用途に使われるのが嫌かもしれません。どのような用途を拒否したいか場合によって異なります。またライセンス設定時点で想定しえない用途があるかもしれません。そこで、作者は用途制限を記述できて、随時変更できます。

コンピューターへのプリインストールについての条項は、バーチャルプラットフォームなソフトウェア資産を蓄積して新たなプラットフォームを発生させるという思想からです。

TenyuLicense

TenyuLicenseで公開された知財（以下、対象知財）は、以下の条件でその著作権によって守られる範囲の一部を許可する。

あなたの制作に対象知財を利用する場合、以下の条件を全て満たす場合に限り対象知財を素材または部品として利用する事、改変する事、再配布する事が許可される。

作者権侵害を起こさない。
プロジェクト権侵害を起こさない。
あなたのサイト等主な情報発信手段を通じてあなたの公開鍵を宣言し、秘密鍵を流出させず、あなたの制作物のURLやあなたの制作物が対象知財から受けた貢献についてTenyuの相互評価フローネットワークに記述する。Tenyuの相互評価フローネットワークが利用できない場合、あなたの制作物とあなたの最も継続的な情報発信手段となっているサイトで記述する。
あなたの制作物が有償販売されるソフトウェアではない。ただし、Tenyuの相互評価フローネットワークで仮想通貨分配を受ける行為はここで有償販売とみなさない。さらに、あなたの制作物が有償のコンピューターにプリインストールされるソフトウェアで、そのプリインストールされるソフトウェアが持つ価値がそのコンピューターの価格に含まれないなら、有償販売とみなさない。
あなたの制作物にあなたの創作性が強く含められている。
これらの条件が履行されているかの判定が難しい場合、その判定がTenyuの全体運営者またはTenyuの全体運営者からその役割を委任された者に委ねられる事を承諾する。
あなたの制作物がソフトウェアならTenyuLicenseで公開される。
対象知財のライセンスとしてTenyuLicenseと共に用途制限が記述されていた場合、それに従う事。用途制限は随時更新される可能性がある。あなたの制作物のライセンスは対象知財の用途制限を継承する必要がある。

独自用語ないし解釈

FOSSとは

世界の共用資産として供されるソフトウェア

MMOとは

私が初めてMMOをやったのは14歳の時で、PHIというMMOでした。世界に降り立った直後、何をするゲームなのか分からなかったので、周囲に居た人に尋ねました。「このゲーム何をしたらクリアなの？」相手はこう答えました。「MMOだから、クリアとかないよ」私はそれまでSFCやPSのゲームしかやったことが無かったので、当初その言葉の意味が分かりませんでした。それから私は様々なMMOをプレイしてそれがどのようなものか分かりました。

実際、MMOはクリアとなる条件がありません。MMOの中にも部分的にはクエストをクリアするとかボスを倒すといったクリア可能なゲームとして捉えれる部分があります。しかし、あくまで部分的です。ゲームは勝利条件ないし終了条件が構成要素として必ずあります。MMOで、誰が何を達成すればゲームが終わるか？そのような条件はありません。私の意見では、MMOは部分的にゲームだが全体としてゲームではない。

MMOの重要な特徴は、クリエイターによる制作、サーバーによるサービス提供、ユーザーによるアイテムの入手と消費に至るまですべてがオンラインで完結しうること、そして巨大なRMT市場を実現したことです。MMOの本質は仮想経済です。

一般にMMOプレイヤーはゲームのアクション性やグラフィックや音楽等を楽しんでいるというよりゲーム内資産の蓄積を楽しんでいます。もちろんアクション性、グラフィック、音楽なども重要ですが、オマケに過ぎません。プレイヤーを動かすのはMMO上での価値（レアリティ、市場価格等）です。この点でまさにMMOプレイヤーはそれを（従来のSFCやPSなどの）ゲームとして楽しんでいるのではなく仮想経済として楽しんでいるのです。

MMOでは、フィールド狩りや戦争やインスタンスダンジョン等様々なコンテンツがありますが、それらはどのように設計してもいいわけではありません。大勢のプレイヤーが報酬のために貪欲に活動するから不正行為が発生したり、報酬が強いコンテンツにプレイヤーが集中し報酬が弱いコンテンツが廃れたりします。膨大なプレイヤーが貪欲に参加しつつ多様なコンテンツが常に活性化される理想的な動態を作り出す事などを考えると、仮想経済（MMOの要素の中でも報酬や経済のシステム）と呼ぶべき問題領域がある事が分かります。

本構想はMMOが進歩したもので、仮想経済という問題領域への独自の回答を持ちます。

創作とは

まだ実現された事が無いものを発想する行為及びそれを文章やプログラムや絵や音楽等で実現する行為。

創作は発想と実現する事両方が構成要件です。ものによって発想と実現どちらが重視されるか違うと思います。 創作への貢献度はどこに難しさがあって誰がそれを解決したかで決まると思います。創作的成果は社会に予測不可能な変化をもたらす場合があります。

創作活動が民間資本でうまく扱えない理由を説明します。以下の理由から創作活動は本質的に経営困難です。

アイデアを思いつく方法論は確立していません。
創作活動の成功率やインパクトは予測不可能です。
しばしば作者が交換困難で、しかし職業選択の自由から企業が作者を確保し続けれる保証はありません。
奴隷労働のように無理やり働かせてもダメで、優れた創作は作者の主体的努力によってのみ可能です。
創作活動の成果が出るペースを引き上げようと思っても人海戦術が効かないし、システマティックな生産体制は発想を制限する可能性が高くインパクトが低減する可能性があります。
創作活動の成果を評価するのは難しいです。売上に応じて評価するのは妥当ではありません。本当に新しいアイデアをもたらした作品が商業的にはあまり成功せず、それをブラッシュアップした作品が成功する場合もあります。企業としては売上があるから問題無いかもしれませんが、他人の作品をブラッシュアップする事は創作活動としては下流工程であり本質的ではありません。
心理学で"内発的動機付け"と呼ばれているものがあります。私の考えでは創作意欲はその一種ですが、他者からの命令や金銭的報酬は内発的動機づけを阻害すると言われています。内発的動機づけは人間が自己決定可能である事を示すものだからです。自由に自分の興味本位で創作できる事が大切です。創作活動の動機

やりがい搾取は内発的動機づけの搾取です。クリエイティブ系の企業がそれで槍玉に挙がることが多い。しかし、実際にクリエイティブな仕事はやりがい＝内発的動機づけで制作にあたってもらう必要があり、しかも下手な金銭的報酬は内発的動機づけを低下させるので難しい。

以上の理由から民間資本は創作活動をうまく扱えない可能性が高い。民間資本は確実に制作できる部分のみを作り本当に創作的な部分については既存作品の真似で済ます事が多い。例えばMMOではWoWクローンが多い。ブラッシュアップの仕方を変えているだけ、つまり下流工程を変えているだけで本質的な変化がありません。予算規模が大きいプロジェクトほど確実に利益を出す必要があり既存の成功例の模倣になる傾向があります。しかし本当に必要なのは本質的創作であり、根本的な変化です。

解決策があります。ソフトウェアにおける創作に限れば予算や資格がほとんど不要であり敷居が低いので個人での創作活動が可能で、作者があくまで個人として活動する事で作者の退職によって創作活動が頓挫するリスクが無くなります。労働者としてではなくライフワークとして創作活動をすれば一生取り組むことになるということです。多数の作者が相互評価することで商業的評価ではなく創作的評価が明らかになります。新しいアイデアをもたらした作品こそが優れた創作的成果で、売上は無関係です。「誰でもアイデアを思い付いた時に創作活動をする」そのような不定期な取り組みを可能にするプラットフォームが必要です。企業だと雇用してみたけど創作的成果が出なかったというリスクが問題になり、定期的な成果を要求されます。しかし本当の創作的成果は計画的に生産できるものではありません。さらにソフトウェアは他のソフトウェアを参考にしたり部品として利用する事が可能です。相互利用しやすいライセンスを定義して人々がそのライセンスでソフトウェアを公開する事で利用可能なソフトウェアが増加し、私の言葉で言えばそれは世界の共用資産が増加しているということですが、その結果徐々に個人でも高度なソフトウェアを作れるようになるはずです。私はそのようなライセンスをTenyuLicenseとして定義しました。

これらの性質を考慮すると、(本質的な)創作活動は基本的に個人が低コストかつ不定期に行うものだと想定すべきであり、それはこれまで弱者であることが多かった個人が主役となる時代を主張するものです。とはいえソフトウェア制作は多様であり、私が主張している事が実現され大抵のソフトウェアが個人によって作られるようになったとしてもなお企業が作るべきソフトウェアは存在すると思います。大規模なものやハードウェアに近いものなど。

創作活動の動機

創作意欲が内発的動機づけの一種であるという考えによれば、この一文は雇用や資本主義や市場経済等の論理が創作活動に適さないことを示しています。
http://www.n-seiryo.ac.jp/~usui/sigoto/gakkai/niigata97.5.31.html

1）金銭報酬は、内発的動機づけを低下させる。

https://warakunomichi.jp/motivation3-0

内発的動機づけを失わせる。

ちなみに私の経験上、ある種の自由度が高いMMOでアイテムやゲーム内マネーを手に入れる事は内発的動機づけをむしろ強化する事があります。理由は分かりません。恐らくそこに「命令」が無く「自由」であると感じているからです。本当に創作意欲を殺しているのは金銭報酬よりも「命令」「従属」といった事かもしれません。

しかし内発的動機づけだけでは優れた創作的成果を挙げても社会に提供せずに終わります。創作が楽しい、作った、終わり。社会に提供する必要性がありません。社会と関わる事は様々なリスクや葛藤や苦労の原因だから外発的動機づけがなければ関わりません。私の考えでは、創作活動における適切な外発的動機づけは創発的現象を求める事です。自分の想像を超えた事になるかもしれないという点に創作者として魅力を感じるべきです。

創発
https://kotobank.jp/word/%E5%89%B5%E7%99%BA-552975

意図を超えたイノベーションが誘発されるところから「創発」と呼ばれ

創作活動は従来「やりがい（内発的動機づけ）」に頼っていた面がありますが、創作活動のためのシステムを真面目に考えるべきだと思います。 創作活動における金銭報酬はどの程度創発的現象に貢献したかに応じて与えられるべきです。それが創作活動をする者として唯一の健全な外発的動機だと私は考えています。商業的な売上ではなく、二次創作をどの程度生み出したか、後の作品にどの程度影響を与えたかなどで報酬が決定すべきという事です。（相互評価フローネットワークでたくさんエッジを受ける事がそれ）即ちあるべき報酬額は売上と連動せず派生作品の増加にこそ連動するのであり、売上を得ている者が報酬を支払うというアイデアは通用せず、報酬を支払う者は人ではなく全体を代表する資金が枯渇しない特別な主体（共同主体）である必要があります。 Tenyuの報酬システム（相互評価フローネットワーク）はそれを実現します。

ソフトウェアの経済的性質

従来の経済は人から人へ価値が提供され、提供を受けた側がお金を支払っていました。これはものや時間を収益化する事に適していました。しかしソフトウェアを収益化する場合、その複製が容易であるという性質から、ソフトウェアを世界の共用資産として他者が自由に利用しやすいライセンスで公開する事が世界の生産性を最大化するために望ましく、制作者はその世界の共用資産として制作物を供しているという点から報酬を受け取るべきで、即ち個々のソフトウェア利用者が支払いをするのではなく全体を代表する特別な主体が世界の共用資産の保有者として支払いをするのが妥当です。Tenyuでその特別な主体は共同主体と呼ばれます。

さらに、ソフトウェアは創発的現象を非常に起こしやすく、創発的現象への貢献に応じて収益化されるシステムが望ましい。さらに、ソフトウェアは世界的に複製される事から、その全体を代表する主体は世界的なP2Pシステムで実現される事が望ましい。

承認情報

まず、非承認情報は例えばニュースや動画など情報の取得を本質とします。承認情報はオンラインゲームのアイテムデータ等情報がどこかに保持される事を本質とします。オンラインゲームのアイテムデータは従来の方法ではゲームサーバーに保存されます。もしゲームサーバーのDBをもらってもプレイヤーは嬉しくありません。大勢のプレイヤーが共用しているサーバーにデータが保持される事が本質です。そのような情報を承認情報と呼びます。承認情報は必ずしもサーバーに保存されるわけではなく、P2P承認情報基盤もあります。

承認情報基盤

承認情報のCRUDが可能で恣意的改ざんを受けないシステム。ゲームサーバー、一部のP2Pネットワークなど。例えばオンラインゲームのサーバーは各プレイヤーキャラクターのレベルやアイテム所有情報等の承認情報を作成、更新、あるいは削除して、それら情報を多くのプレイヤーに送信し、承認情報のCRUDを実現しています。

承認情報基盤は攻撃に晒されやすいです。そこに価値ある情報が記録されているのでそれを改ざんできる事に価値があるからです。承認情報基盤はセキュリティを達成する必要があります。それが達成されると価値が高い承認情報を保持できるようになります。

P2P承認情報基盤

承認情報基盤をP2Pネットワークで実現する事が可能です。P2Pは承認情報基盤としてC/Sと決定的に異なります。C/Sは運営による不正行為やサービス終了を防げません。P2Pは誰もが状態遷移を監視できて不正を監視可能で僅かでも需要がある限りサービスが継続されます。そしてP2Pは選挙的な機能を実現できます。共同主体のような全体を代表する主体を作るためにP2Pは適しています。

資本

私は本構想がソフトウェア領域のための新たな資本モデルであると主張します。私の資本についての理解を説明します。

資本は事業形成能力であり、多くの場合反復的な自己強化サイクルを持ちます。資金力や設備や周囲からの認知など様々なものが事業形成能力に含まれます。

私は、このTenyuプロジェクトを通じて主張しているソフトウェアのための資本モデルを共同資本と呼びます。うまくいけばそれは仮想通貨の価値、TenyuLicenseのソフトウェアの数や規模、相互評価フローネットワークの複雑さ、ユーザー数を反復的に強化します。それらはいずれもそれらを強化する理由になるから反復的強化が発生します。

共同資本の特徴

オンライン上の（＝国境を容易に越えれる）自動化されたシステム
創発的現象に期待する楽観的なもの
初期投資できない
特殊な選挙的プロセスによる運営者選出
完全な透明性
ソフトウェア及び知識生産を主領域とする。共同資本はほとんどのソフトウェアや知識の生産活動をその構想上で扱えますが、世界的な共用の必要性が高いソフトウェアまたは知識が主領域となります。ソフトウェアでも例えば特殊なハードウェア専用のデバイスドライバは適さない可能性が高いです。

共同資本と政府資本、民間資本の違いについて。

政府資本は権力を通じて国内全体に強制的に作用できます。共同資本は現実社会に強制力を持たないので政府資本と役割が被りません。

民間資本は独断的な投資が可能で、工業等の初期投資を必要とする事業に適しています。共同資本は初期投資を扱えないので民間資本と役割が被りません。

共同資本は世界の共用資産となるべきソフトウェアや知識の生産に向いた資本です。ソフトウェアを他者が利用しやすいライセンスで公開し世界の共用資産とする等、最も創発的な選択をする事が前提にあり、報酬の支払者は共同主体という全体を代表する特別な主体のみが行い、個々の参加者は支払いません。 Tenyuがもし世界的に普及したという前提で考えると、共同主体から報酬が支払われる事は「世界の共用資産への貢献に応じて報酬が支払われている」と解釈できます。誰にいくら報酬が支払われるかは多数のユーザーによってつくられる相互評価フローネットワークによって決定されます。 Tenyu基盤ソフトウェアが備えるP2P技術及び仕様によって、このシステムは完全な透明性があり誰も恣意的に改ざんできません。

後述する連合型MMOによって仮想通貨に価値を持たせ、相互評価フローネットワークによってクリエイターに仮想通貨を分配し、制作者はエッジ獲得のためにソフトウェアを制作しTenyuLicenseで公開し、ソフトウェアが共有される事で他の人が新たなソフトウェアを作り易くなり、そうして作り易くなったソフトウェアの中にはゲームで使用可能なものも含まれ仮想経済が加速し仮想通貨の価値が向上し、TenyuLicenseに従ってエッジを作成していくことで一貫したルールの元で相互評価フローネットワークが発達し、相互評価フローネットワークの発達と安定が新たな参加者を呼び込み、これらサイクルが反復的に繰り返され強化され続けます。そのサイクルの中でネット上で共有されたソフトウェアの増加や制作者のソフトウェアスキルの向上、制作者間の相互評価や信頼の構築が起こります。 本構想が十分に達成されると、相互評価フローネットワークはソフトウェアの汎用的なマネタイズ手段として確立します。

共同資本は世界で１つであるべきです。インターネットで世界的な情報の拡散が容易に発生するからです。ソフトウェアや知識の拡散に障壁を作る事は困難です。ネットがある事でソフトウェアや知識の生産において世界的な相互の貢献が容易に起こるので、その貢献に基づいた報酬システムは世界で1つであるべきです。

仮想通貨

一般に仮想通貨はP2P承認情報基盤で管理された量で、ユーザー間で取引可能で、たまに新規発行される事を除けば原則として保存量であり、多くの人々によって通貨として承認されたものです。特にTenyuの仮想通貨は連合型MMOにおいてゲーム内マネーとして使用できます。

仮想通貨はいくらでも作り出せるデータで大勢の参加者に与える事が可能です。いくらでも作り出せるからといって必ずしも価値を持たないわけではありません。例えばMMOのゲーム内通貨もいくらでも作り出せるデータですがRMTで取引されるなど価値を持ちました。参加者数が多く、めちゃくちゃな運用がされないという信頼性があれば、仮想通貨は価値を持ちます。

コモンウェルス

コモンウェルスの原義は共通善ないし「公衆の財産としての公共体」とされている。しかし私は「コモンウェルスは公衆の環境的財産」だと思っている。

私がコモンウェルス（公衆の環境的財産）だと認識するものの例

公用語の普及。どこに行っても同じ言語が通じることは全員の利益であり環境的財産。
法律が遵守される（ある種の一貫性がある）状況。どこに行っても同じ法律が守られている事はしばしば全員の利益になる。例えば車が右側通行か左側通行か統一されている事は全員の利益であり環境的財産。
国内に強制力を持つ（環境整備できる）政府。コモンウェルスはある種の統一による利益（ほぼ全員が十分に遵守した場合に生じる利益）であることが多く、政府の強制力によって統一が図られる事が多い。
他のコモンウェルスが侵入してこない（１つの政府のみに統治権が認められた）領土。

国や連合の名前にコモンウェルス(commonwealth)ないし同義語とされるRepublicという語が用いられる場合がある。コモンウェルスという概念は領土（環境的財産が存在する範囲）や公衆（環境的財産を認識する存在）や政府（国内での統一を実現する能力の一種）と本質的に関係している。

「実態に基づいた社会的認識を持てる社会」をある種の環境的財産と捉えれば、私が主張する作者権等はコモンウェルスからも説明される。

相互評価フローネットワーク

ほとんどあらゆるソフトウェアや知識の生産活動を収益化するため、創作者による相互評価が記述されたフローネットワークです。このネットワーク上で評価される事で仮想通貨分配を受けられます。

従来ソフトウェアはマネタイズの方法が確立していませんでした。ソフトウェア特許や著作権によるマネタイズは他者によるソフトウェアの自由な利用を阻害する等問題を伴いました。相互評価フローネットワークはソフトウェアのほぼ自由な利用を推進しつつソフトウェアのほぼ汎用的なマネタイズを実現します。

汎用的かつ便利な収益化システムが確立すると、ソフトウェアの開発終了やオンラインサービスの終了を防止できて、人的動態の維持発展が促進されます。

一般論としてこれまで産業において細かなアイデアやソフトウェア的貢献は報酬が支払われていなかった場合があったとされますが、より厳密な報酬分配を自動化されたシステムで達成します。

アイデアや発明等が促進されるプラットフォームが確立する事は文明上の重大な意義があります。人々にとって絶望的問題とは少なくとも解決策が存在しない問題ですが、アイデア（解決策）を記述した文章はある種のソフトウェアとしてこの発明で促進される対象であり、この発明は人々の課題解決能力の最大化に寄与します。

相互評価フローネットワークは多様なユーザーの判断で作成されるので、通貨の分配経路は複雑化し、細かく貢献を認める事が可能です。

以下、相互評価フローネットワークについて詳述します。

有向グラフ

有向グラフでGoogle検索すると丸と矢印の図が出てくると思います。丸はノード、矢印はエッジです。ノードは様々な対象に対応します。矢印に重み（その矢印の太さ、強さみたいなイメージ）を設定できます。フローは、どこかのノードから発生してエッジの上を流れていく量で、より重みが強いエッジほどより多くのフローが流れます。だから、よりたくさんのより強いエッジを受けているノードはより大きなフローを獲得します。

エッジ作成操作

ユーザーはTenyuのGUIからエッジを作成できます。エッジは仮想通貨分配額を決定する重要な承認情報なので改ざん困難な方法で記録されます（客観DBに記録される）。相互評価フローネットワーク上には様々なノードがありますが、それぞれ管理者ユーザーが設定されていて、管理者のみがそのノードからのエッジを作成できます。全体運営者に選出されると共同主体ノードの管理者になるし、もしあなたがWEBページにおいてURL証明を終えていたらそのWEBページノードからのエッジを作成できます。もしあなたがゲームの運営者として登録されていたら、そのゲームノードからのエッジを作成できます。ユーザーノードというのもあり、誰もが自分のユーザーノードからのエッジを作成できます。

相互評価フローネットワークはある種の有向グラフで、A→BはAがBから貢献を受けた事を意味します。エッジの重みはどれくらい大きな貢献を受けたかを意味します。便宜的に説明すると、AさんはBさんがこれくらい好き、AさんはWEBページ１がこれくらい好き、という感じでエッジを作っていきます。重みは、自分に流れ込んだフローの何％がその人に流れ込むか、という事です。共同主体から最初のフローが湧き出て相互評価フローネットワークを流れて、各ノードに流れ込むフローの多さが仮想通貨分配量を決定します。自分が尊重すべき人やものにエッジを作成していきますが、少し尊重できるもの大いに尊重できるものなどあると思いますが、その差別化をエッジの重みの差として表現できます。そしてTenyuは創作活動による経済なので、主に創作的貢献についてエッジを作成します。

例えばこんな重みをつけたとします。赤い1200が流入フローで、各エッジの割合に応じてフローが分割されます。大勢のユーザーが様々なノードについてエッジ作成活動をすると、全体として複雑なネットワークができます。WEBページはその制作者や素材提供者にエッジを作成し、ゲームは衛星作品や運営者や創作者にエッジを作成し、創作者は影響を受けた学習サイトや他作品のWEBページにエッジを作成します。総じて言えば、オンライン上の貢献関係についてエッジを作成していくわけです。緑の旗は後述する共同主体を意味します。共同主体からフローが湧き出て、そのフローの到達量に応じて仮想通貨が分配されます。黄色の旗はオンラインゲーム、動物の顔はユーザー、GUIのようなものはWebページです。複雑なネットワークができると様々な経路でフローが到達します。

エッジ作成のルール

エッジは公開された成果に対して作成する必要があります。非公開の成果に作成する事は場合によってBANの理由になります。身内でエッジを作り合って不正に報酬を得る行為が疑われるからです。

フロー計算

画像の黒い矢印はエッジです。一般にフロー計算では任意のノードを始点にできますが、相互評価フローネットワークでは共同主体が始点になります。始点では次数０です。赤色の帯はフローです。フローはある種の量で、エネルギーのようなものと捉えておいて問題ありません。（フローは普通は歪対称性が定義され他のフローと衝突しますが本構想の相互評価フローネットワークのフロー計算では衝突しません。A→Bの流れがありつつB→Aの流れがあるということがありえます）

画像は、始点の近傍にフローが流れた場面です。フローがノードに到達すると、そのノードの到達フローに加算されます。ネットワークが複雑になると、ノードは様々な経路でフローを獲得しますが、その合計値が到達フローです。この段階は次数１です。次数はフローが経由したエッジ数と定義できます。フローはノードに到達した後、そのノードの全てのエッジに分割されてその近傍へと流れていきます。さらにフローが流れ次数２になりました。次数３です。このようにしてフローが流れ、各ノードの到達フローが計算されます。ただし、次数に上限があり、おおよそ６～７です。始点からあまりに遠いところまで流れないということです。それは単に計算量が大きすぎるからです。次数が１増えるたびに計算量が１００倍程度に急増します。最終的に各ノードの到達フローが決定し、その比に応じて仮想通貨分配額が決定します。

次数補正

より厳密には次数補正というアイデアがありエッジを経た回数で補正がかかります。次数補正の係数cは全体運営者が設定できて、相互評価フローネットワーク全体で一定です。例えばエッジを経るたびに1.05がかけられるとすると、より根本から離れた、共同主体から離れたノードが収益化されやすくなります。なおそのような場合でも「公開された成果にエッジを作成する」というルールがあるので無駄にエッジを重ねる事はできません。

フローはエッジを経るたびに次数が1増加します。次数はいくつエッジを通過したかという数値です。フローはネットワークを辿る中で急激に分散し、ネットワークの末端まで十分に届きません。そこで、次数補正は末端までフローが行き渡るよう、フローを強化するために設定されます。係数は全体運営者が設定します。この仕様は相互評価フローネットワークによる仮想通貨分配において中心付近でなくとも十分に仮想通貨分配を受けれるようにするための仕様です。ネットワークの発達に応じて徐々に外側で大きな分配が受けれるように調節する事を想定しています。

ダミーアカウント問題と格差是正

ユーザーによって到達フローに大きな差が生じる可能性があり、それは獲得できる仮想通貨量に影響します。しかしその差を是正しようというアイデアはうまくいきません。どのような是正方法であれ、ユーザーは複数のユーザーアカウントを作成して貢献度を分散させる事で大量にフローを得ている事を隠せるからです。大量にフローを得ているユーザーに対して結果の平等のためにそれを是正しようとすると、ユーザーはアカウントを大量作成して1アカウントあたりの獲得フローを小さくする事で是正を回避できるということです。オンラインシステムではこのようなダミーアカウント問題が付きまといます。だから格差是正の方法はありません。実社会の累進課税のようなアイデアはダミーアカウント問題を抱えるネットの世界において通用しません。

ノードとエッジの種類

ノードやエッジは種類があります。

特に抽象ノードという仕組みを通じて任意の対象を仮想通貨分配の対象にできます。その汎用的な収益化能力から、抽象ノードはFOSSを収益化する事を可能にします。

ノードの種類 ノードの種類毎に管理者を決定する手順が違います。管理者はそのノードからのエッジを作成する権限を持ちます。

共同主体共同主体は全体を代表するノードで、相互評価フローネットワーク全体で1つしか存在しません。全体運営者が管理者になります。つまり分散合意による選挙的プロセスによって管理者が決定されます。共同主体からのエッジは基本的に抽象ノードに向けて作成されます。
抽象抽象ノードは共同主体からのエッジを受ける事ができる唯一のノードで、複数存在します。例えば「OSS」という抽象ノードが作られてそこから各種OSSにエッジを作成します。OSSは一般ユーザーの間の相互評価でもエッジを獲得する可能性がありますが、抽象ノードからトップダウン的な方法でもエッジを獲得する場合があります。OSS以外にも様々な抽象ノードが考えられます。一部の標準的な抽象ノードはエッジ作成が一定のアルゴリズムによって自動的に作成されます。例えばレーティングゲーム抽象ノードは各レーティングゲームのアイテム売上に応じてそのゲームにエッジを作成します。レーティングゲームの売上は共同主体に回収され相互評価フローネットワークを流れますが、レーティングゲーム抽象ノードからのエッジが売上に応じて強化されるので、個々のゲームに売上を伸ばすインセンティブが存在します。抽象ノードの管理者は全体運営者が指名したユーザーまたは無人です。無人の抽象ノードはアルゴリズムによって自動的にエッジ作成をします。なおこの文書で共同主体からエッジが作成されると書かれていた時、抽象ノードを経由して作成される事を意味している場合があります。実際、抽象ノードは共同主体からのエッジを分類するため、エッジ作成作業を多数のユーザーで分担するために存在します。参照：抽象ノードの種類
レーティングゲームゲームの登録申請者が管理者になります。ここから各ゲームにそのゲームの装備売上に応じて自動的にエッジが作成されます。
常駐空間ゲームゲームの登録申請者が管理者になります。ここから各ゲームにそのゲームの装備売上に応じて自動的にエッジが作成されます。
ユーザーユーザーノードはユーザー登録に伴い作成され、そのユーザーが管理者になります。
WEBページ WEBページはWWWの任意のWEBページで、URL証明を通じて管理者を決定します。

抽象ノードの種類

基盤ソフトウェア共同主体のソフトウェア、つまりTenyuを意味します。ここからTenyuの基盤ソフトウェア開発に貢献したノードにエッジが作成されます。
運営本構想全体の運営に貢献した人にここからエッジが作成されます。主に全体運営者または全体運営者が特別な役割を任命したユーザーに作成されます。全体運営者が自分へのエッジの重みを決定できてしまうとまずいので、共同主体から運営抽象ノードへのエッジの重みは予め固定値が与えられていて変化しません。
立ち上げ協力者本構想の立ち上げに協力した人にここからエッジが作成されます。
OSS 例えばJDKやLinuxなど広く利用されているソフトウェアに対して共同主体が全ノードを代表してエッジを作成するときにここから作成されます。
レーティングゲーム全レーティングゲームを代表する抽象ノード。ここから各レーティングゲームにそのゲームのアイテム売上に応じてエッジが作成されます。つまりこのノードは無人であり、自動的にエッジが作成されます。
常駐空間ゲーム全常駐空間ゲームを代表する抽象ノード。これも無人でアイテム売上に応じて各常駐空間ゲームにエッジを作成します。

エッジの種類

エッジの種類はおおよそどのような理由でエッジを作成すべきかを示します。一般にエッジはノードが他のノードから貢献を受けた場合に作成します。エッジの種類によって仮想通貨分配で使用されるかが異なります。例えば運営貢献や参加貢献や部品貢献や制作貢献等は仮想通貨分配に影響しますが、友人エッジは影響しません。仮想通貨分配に影響しないエッジは基本的に無意味ですが、もしかしたらゲームで利用されるとかあるかもしれません。

運営貢献共同主体の運営者は選出された時点で予め定められた重みのエッジを受けます。
参加貢献特別な貢献をしたプレイヤーや有名で宣伝効果があったプレイヤー等に作成。
部品貢献イブラリや素材の提供者に対して作成されます。例えばソフトウェアを公開しているWEBページから、そのソフトウェアにおいて利用されたライブラリのWEBページへとエッジが作成されます。
制作貢献ソフトウェアの制作者に作成されます。例えばソフトウェアを公開しているWEBページから、そのソフトウェアの制作者のユーザーノードへとエッジが作成されます。
尊敬
学習
ファン
友人
回収貢献装備売上に応じて作成される場合等。
その他

１シナリオ

Tenyuは連合型MMOを実現するので様々なゲームが登録されますが、1つレーティングゲームが登録されたとします。ゲームAとします。ゲームAの周辺にはその制作者、使用されたライブラリ及びライブラリの制作者、宣伝した者が存在します。その場合このようなエッジが作成されます。
ゲームA→ゲームAの制作者
ゲームA→使用したライブラリ→ライブラリの制作者
ゲームA→関連する実況プレイ動画URL→実況プレイ動画の制作者

さらに、前述したようにレーティングゲーム抽象ノードがアイテム売上に応じて自動的にエッジを作成します。
共同主体→レーティングゲーム抽象ノード→ゲームA
だからこのような経路も存在します。そして前述した経路と合わせると、共同主体からゲームAの制作者、ライブラリの制作者、実況プレイ動画の制作者まで経路が実現し、仮想通貨分配の対象となります。

これらエッジは、何が何から貢献を受けたかという事を意味しています。エッジは一貫して貢献を受けた事に応じて作成されます。

主旨

ところで、貢献に応じてエッジが作成されるなら、そしてエッジに応じて仮想通貨が得られるなら、自身が持つソフトウェアを利用しやすいライセンスで公開して多大な貢献をすれば多大な仮想通貨が得られる事を意味します。有用なソフトウェアの公開と自由に利用される事が報酬の増加につながる事が相互評価フローネットワークの主旨です。
（その状況を前提とすると著作権は過剰な保護であり、作者権で十分であると分かります）
構想が実現すれば、相互評価フローネットワークによって様々なものに報酬を出せる可能性があります。例えば抽象ノードはOSS全般を収益化できる概念です。運営者の信頼性に依存しますが、Tenyu上で扱われるものかURLがあるものは何でも分配対象にできるし、オンラインゲーム主軸モデルが示すように分配対象にされたものはそれに貢献した様々なものを連鎖的に分配対象にできます。例えばハードウェアの設計もオープンソースの場合があり支援できる可能性があります。その他、新しいアイデアも文章で説明すればソフトウェアであり、本構想で収益化可能です。

共同主体の重要性

相互評価フローネットワークのノードの中に１つだけ共同主体と呼ばれる仮想的なノードがあり、画像では緑色の旗で表現されます。定期的に共同主体の仮想通貨残高の一定割合が相互評価フローネットワークを通じて分配されます。共同主体からのエッジを誰が作るかは重要な問題です。共同主体からどれだけフローが届いたかで各ユーザーへの仮想通貨分配量が決定するからです。選挙によって選出された全体運営者が共同主体からのエッジを作成します。一部のエッジはアルゴリズムによって自動的に作成されますが、全体運営者はソフトウェアの次のバージョンを指定する権限もある(作者の署名も必要)ので、全体運営者はそのアルゴリズムについても決定権の半分を持っています。全体運営者は選挙によって複数選出され全体運営者ごとに影響力割合が設定されます。最大の影響力割合を持つ全体運営者だけが出来る事があったり、全体運営者の中でさらに投票が行われたりします。

URL証明

WEBページはコメント欄など誰でも書き込める部分と管理者しか書き込めない部分があります。URL証明において、証明者は管理者しか書き込めない部分にURL証明コードを挿入します。そうすると、URL証明コードにTenyuのユーザーIDやそのユーザーの電子署名が含まれているので、Tenyuのシステム上でどのユーザーがそのWEBページを管理しているかが分かります。URL証明に成功すると相互評価フローネットワーク上にWEBページノードが作成されます。例えば動画のWEBページはアップロード者による動画説明文を書く欄があり、そこはアップロード者しか編集できず、管理者証明に使用可能です。一方で不特定多数のユーザーのためのコメント欄が様々なWEBページにありますが、そのような部分は誰もが書き込めるので管理者証明に使えません。 HEADタグは一般的に管理者しか書き込めないので全サイト共通の管理者証明に使用可能な部分ですが、完全に自前のサイトの場合HEADタグを編集できますが、一部のサイトはHEADタグを修正できません。そのようなサイトはTenyuが個別に対応し、管理者しか書き込めない部分を特定してURL証明に使えるようにします。サイトは多くの場合どこかに管理者しか編集できない箇所があるので、サイト側は特別な対応が必要ありません。

URL証明コードは公開鍵と署名が含まれるので、そのWEBページの管理者の公開鍵を証明できます。Tenyuは公開鍵とユーザーIDの対応関係を統一値として持っているので、URL証明によってそのURLの管理者のユーザーIDを決定できます。つまり、相互評価フローネットワークが扱えるWEBページは特定のサイトに限定されず、ほとんど全てのWEBページを対象にできます。もしあなたがこれまでどこかのサイトにブログを書いたり、動画をアップロードしたり、プログラムのソースコードを公開したりしているなら、それらは相互評価フローネットワーク上のWEBページノードとして扱えます。サイトが対応しているかを気にする必要はありません。Tenyuがそのサイトに対応しているかだけが問題になります。 URL証明によってWEBページの管理者であることを証明できたら、そのWEBページノードから自分にエッジを作成できます。

URL証明はWEBページにアクセスしてHTMLを取得した人においてURLと公開鍵の対応関係が証明されるということですが、P2Pネットワークの全ノードがアクセスすると過剰な負荷をかけます。しかし、過半数のノードがURLと管理者公開鍵の対応関係について納得しなければ、統一値になりません。P2P承認情報基盤はそのP2P技術によって選挙的プロセスを実施できて全体運営者を選出できますが、全体運営者はそのWWWアクセス役（URL証明サーバー）など特別な役割を指定したユーザーに与える事ができます。即ち選挙技術を持つTenyuだからこそ任意のWEBページを扱えます。URL証明におけるWEBページへのアクセスはWWWアクセス役に指定されたユーザーのみが行います。WWWアクセス役に選ばれたユーザーはFQDN（良くドメインと呼ばれる）を持つ必要があります。URL証明したいユーザーがTenyuのGUI上でその操作をすると、WWWアクセス役に自分のWEBページのURLを送る事ができて、WWWアクセス役のソフトウェアは自動的にURLにアクセスしてURL証明コードを確認します。確認できたら、WWWアクセス役はP2Pネットワークに自身の電子署名をつけて報告します。各ノードはWWWアクセス役の電子署名があることをもってその報告を受け入れ、WEBページと管理者公開鍵の対応関係が統一値になります。

MMO構想

MMOとソフトウェア収益化システムの関係

ソフトウェア一般の収益化問題とMMOというゲームの問題は一見関係が無さそうですが、そうではありません。MMOはクリエイターによる制作、サーバーによるサービス提供、ユーザーによるアイテムの購入や使用に至るまで最も純粋にオンラインで完結しうる特殊な経済で、その制作はほぼ純粋にソフトウェア制作であり、ソフトウェアの自由な相互利用が促進された場合MMOの開発効率は飛躍的に高まり同時にMMOを通じて経済を回せます。だからネット全体に跨るソフトウェアの汎用的収益化システムを構想するならMMOは考慮する価値があります。そして私はMMOを組み込む事でソフトウェアのマネタイズ問題を（構想上）解決しました。

仮想経済

私が使用する仮想経済という語は私の造語です。あるいは同様の話が他でも既に書かれているかもしれません。

仮想経済とは仮想的な価値を生産する経済で、従来の実例ではMMOがあります。MMOを通してRMT市場が創出された事が仮想経済の存在を示しています。

仮想経済(MMO)をどうデザインすべきかは非常に難しい問題です。その問題領域がどんな枠組みの上にあるかというところから問題になります。私の考えでは、ゲームというただの娯楽の問題ではなくソフトウェアのための新たな資本モデルを構想する上で本質的な問題です。私の構想では仮想経済は人々から共同主体へと仮想通貨を回収する役割を持ちます。

Tenyuは仮想経済の設計に対する独自の回答を持ちます。連合型MMO

その他仮想経済に関して。

オンライン上のやり取りだけなので環境負荷が低い。従来型の経済で財政問題を解消しうるほどの経済成長をすると環境が持たないと思われ、仮想経済はほとんど唯一の道だろうと思う。
ITの進歩を促進する可能性がある。
MMOのような仮想的なアイテムを入手する経済ができると社会不適合者の受け皿となる可能性がある。
もし本構想と共にオンラインゲームの制作が活発になると個人制作者が活躍するようになり独創的な作品が増える。
オンラインゲーム主軸モデルによって海賊行為を解決できる。
その入手や使用は自宅に居ながらできるので余暇で生産活動ができる。ゲームプレイという娯楽の時間が生産的な時間になる。
文化的可能性が飛躍的に広がり独創的な価値を生産するようになる。
オンラインゲームのアイテムの多様さ、グレードの幅、必要数は基本的に上限が無いので、上限無き経済成長を達成しうる。従来の消費者向け商品は衣食住に対応していたり場所を取る等してその多様さと必要数は上限があった。
Tenyuの構想では仮想経済がソフトウェアの汎用的な収益化構想に組み込まれ、相互利用しやすいライセンスでソフトウェアが公開され世界の共用資産が増加します。
仮想経済は地方創生に適うかもしれません。

20世紀は工業製品の急速な発達があったが、そのような商品は可能な販売量に限界があるので経済成長に限界がある。環境負荷の問題もある。21世紀はオンラインゲームのアイテムによる場所をとらず環境負荷も限定的な上限の無い経済成長が実現される。この観点はこの記事から影響を受けています。 http://www5b.biglobe.ne.jp/~shu-sato/dc01.htm

関連：なぜ仮想的なアイテムが価値を持つか

連合型MMO

連合型MMOは多数の制作者がそれぞれ小さなゲームを登録して、それらを連携させてMMOを実現します。

連合型MMOはPHIでC/S型とはいえ前例があり、PHIは私が知る限り日本で最も長く続いているMMOです。企業による数々のMMOがサービス終了してきた一方で複数の個人制作者による連合型MMOが最も長く続いたという事実は注目に値します。 Tenyuの連合型MMOは仮想経済の一種で、仮想通貨に価値を持たせる役割があります。

連合型MMOの長所は、1つのゲームが廃れるだけでは重要なゲーム内資産（ゲーム内通貨残高や人間関係）に影響が無い事です。全ゲームで共通の通貨やユーザーDBを使います。従来のMMOは持続可能なモデルではありませんでした。MMOはいずれ廃れてしまいます。廃れてしまえば蓄積されたゲーム内資産は価値を失います。連合型MMOはその問題を解決しています。

Tenyuの連合型MMOでアイテムを仮想通貨で購入すると共同主体の仮想通貨残高へ回収されます。この点で連合型MMOは本構想のエンジン（独自通貨の回収モデル）であると言えます。

以下で述べる事はTenyuの連合型MMOがどうデザインされるかです。

余暇の収益化やネット上の様々な活動の収益化

これらの構想に基づいたオンラインゲームが実現されると余暇を収益化したりオンラインゲームのプレイヤーが経済的理由でリアル破綻しないようにできます。

Tenyuプロジェクトは連合型MMOを構想し、多数のオンラインゲームで共通のゲーム内通貨を用いる事になり一部ゲームが衰退したとしてもゲーム内通貨の価値が保たれるという面があります。プレイヤーは必要ならゲーム内通貨をRMTで販売できるでしょう。

さらに、ネットで金を稼ぎたい人達は大勢いると思いますが、他人から金を回収するというアイデアだけでは限界があります。従来MMOがゲーム内通貨に価値をもたせRMT市場を実現していた事に注目してください。何も存在しないところに純粋にオンラインの活動だけで価値を作り出せる可能性があります。そしてオンラインゲーム主軸モデルによってオンラインゲームに貢献すれば収益化されます。

参加者の立場

ユーザー

Tenyuでユーザー登録した人全体を指します。

全体運営者

全体運営者は独自のP2P技術を通じた選挙によって選出される共同主体の管理者となるユーザーです。任意のユーザーやゲームのBAN、その他全体方針の策定、ソフトウェアの新しいバージョンを承認、仮想通貨分配等に影響する様々な設定、各種特別な役割を担うユーザーの指名などを行います。

全体運営者は複数選出可能で、各全体運営者の影響力の度合いは分散合意で参加者によって設定されます。全体運営者の中での投票機能が実装されます。 P2Pネットワーク勃興当初、作者である私が最初の全体運営者となるよう予めソフトウェアに設定されています。運営者０の状態から勃興させる仕様を考えるのが困難だったからです。

'全体'運営者と言っているのは各ゲームの運営者と区別するためです。全体運営者は連合型MMOの連合全体で、各ゲームの運営者と区別されます。全体運営者はゲーム部分だけでなく相互評価フローネットワークを通じてソフトウェアの汎用的な収益化システムも実現する必要があります。

プレイヤー

ゲームに参加するユーザー。ゲーム毎にユーザー登録する必要は無く、全ゲーム共通のユーザーアカウントが使えます。常駐空間ゲームで材料を獲得したり、各ゲームで装備を購入したり、レーティングゲームの試合を通じてレーティングが算出され仮想通貨を獲得したりします。

ゲームデザイナー

ゲームデザイナーは常駐空間ゲームやレーティングゲームを作成します。基本的想定として、ゲームデザイン、プログラミング、運営を一人で行います。このうち将来的にプログラミングの負荷はソフトウェアの公開が進む事によって低下すると予想しています。制作と運営を同一人物が行うのは、どのような行為を不正行為と考えるかもゲームデザインの一部だからです。

Tenyu基盤ソフトウェアからゲームを登録できます。

さらに、相互評価フローネットワーク上でゲームから作者へのエッジを作成します。

クライアントソフトウェアのソースコードをTenyuLicenseで公開します。クライアントソフトウェアはソースコードを公開する必要があります。実行可能ファイルを含むので、ウイルスやスパイウェアの可能性を排除する必要があるからです。

ゲームデザイナーは自分のゲームのアイテム品目をTenyuに登録します。プレイヤーは仮想通貨でそのアイテムを購入します。ゲームクライアントはプレイヤーが所有するアイテム情報をTenyu基盤ソフトウェアから実行時に取得できるので、ゲームはプレイヤーの所有アイテムを知る事ができます。支払われた仮想通貨は共同主体に回収され、同時に回収額に応じて共同主体からそのゲームへのエッジが強化されます。共同主体→ゲーム系抽象ノード→ゲーム→ゲームデザイナーという経路ができて、仮想通貨分配がゲームデザイナーまで届きます。

ゲームデザイナーは利用した素材等について公正にエッジを作成する必要があります。

一部ファイルはゲームに同梱しなくても実行時に基盤ソフトウェアからロードできます。例えばゲームエンジンは基盤ソフトウェアに同梱されるので、ゲームのファイルサイズをかなり小さくできます。

ゲームはユーザーのアカウント作成等の処理を扱う必要がありません。TenyuがユーザーDBを提供し全ゲーム共通のユーザーDBを使用できます。ユーザーはTenyuにアバター情報を登録していて、ゲームはTenyuから実行時に動的にアバターのファイルを取得できます。アバターが取得できなかった場合のデフォルトアバターを用意する必要があります。

従来存在した多くのMMOは仮想経済の設計に失敗していて問題を抱えましたが、Tenyuが適切なモデルを提供するので各ゲームは仮想経済の設計に悩む必要がありません（あえて拡張的な経済システムを作る事は可能）。具体的にはプレイヤー報酬や材料を消費して装備を購入するシステムがあります。

ゲームはプレイヤーが他のゲームで持っているアイテムの情報やレーティングを取得できるので、他のゲームと連携できます。

Tenyuはユーザープールを洗練していく仕組みがあるので、ゲームはTenyuを通じて不正行為をしないユーザープールにゲームを提供できます。

素材クリエイター

作成した素材を任意のWEBページまたはTenyu上で公開し、相互評価フローネットワーク上で素材から作者である自分へエッジを作成します。他の人が例えばゲーム制作においてその素材を利用した場合、そのゲームからその素材にエッジが作成されるので、共同主体→ゲーム抽象ノード→ゲーム→素材→素材作者という経路が成立し、素材の作者は仮想通貨分配を受けます。

プレイヤーの動態

プレイヤーはまず仮想通貨の獲得を考えます。仮想通貨はレーティングゲームで勝利する事で分配量が増えます。ゲームを有利にするため装備が必要です。装備はTenyuを通じて仮想通貨で購入できます。場合によって材料も必要です。材料は常駐空間ゲームで入手できます。常駐空間ゲームでも装備を購入してゲームを有利にできます。これがプレイヤーの基本的状況です。

クエストの代替

従来のMMOにはクエストがありましたが、Tenyuではクエストを否定し、以下の仕様がクエストの代替になります。

常駐空間ゲームは様々な条件でプレイヤーに材料を与える。例えばボスモンスターの討伐など。どんな条件でどんな材料を与えるかは各常駐空間ゲームが自由に決めれる。どんな品目があるかは各常駐空間ゲームがTenyuに登録できる。基盤ソフトウェアのAPIを通じて常駐空間ゲームは任意のユーザーに材料を与えれる。
各ゲームはそのゲームで購入できる装備の品目を基盤ソフトウェアを通じてP2Pネットワークに登録するが、装備の購入に伴い消費する材料を設定できる。他のゲームが産出する材料でも設定可能。

つまりプレイヤーは装備を購入するために材料が必要な場合があり、材料の収集のために各常駐空間ゲームをプレイしその空間を探索する必要があります。この仕様によってプレイヤーは様々な空間を行き来し様々な材料を揃えて装備を購入するという目的を達成します。言い換えれば必要な材料の設定はクエストのクリア条件に相当し、材料の収集はクエストの進行で、装備がクエストの報酬です。

この設計はクエストと比べると「ストーリー」が無くなっています。ストーリーはオンラインゲームの複雑な要素や多数のプレイヤーの中で自然発生すべきと考えています。

ゲーム内通貨

従来のMMOではゲームをプレイするとゲーム内通貨を獲得できましたが、本構想では仮想通貨を獲得できます。ゲーム内通貨が仮想通貨であることで連合型MMOが可能になります。

不正対策を確実にするため、通貨の獲得手段は単純化されます。従来のMMOは例えばモンスターを倒すと通貨を獲得できましたが、そのようなゲームデザインはBOTという不正行為を呼び込むので許容されません。仮想通貨の獲得手段は相互評価フローネットワークのフロー計算を通じた仮想通貨分配と[プレイヤー報酬](#プレイヤー報酬と他ユーザーからの送金等に限定されます。

装備

アイテムの一種。プレイヤーは装備を購入しゲームで有利になります。購入可能な装備の品目は各ゲームの運営者が登録します。装備購入の際に仮想通貨や材料が必要です。ゲームAの装備をゲームBで使える場合があります。常駐空間ゲームとレーティングゲームいずれも装備品目を登録可能です。

材料

アイテムの一種。材料は常駐空間ゲームをプレイする事で獲得できます。レーティングゲームは材料を生産しません。材料は装備購入の際に消費されます。常駐空間ゲームBが生産する材料をゲームAの装備の購入条件にすれば、ゲームAのプレイヤーはゲームBに流れます。そのような事をゲームAとBが互いにやる事が考えられます。そのように各ゲームは連携できます。

ゲーム

常駐空間ゲームとレーティングゲームがあります。ゲームは仮想通貨や仮想的なアイテムに価値を持たせる役割があり、本構想のエンジンです。本構想において各ゲームは必ずギルドが制作および運営します。

ゲームクライアント

本構想に限らず、一般にエンドユーザー環境で実行されるプログラムのソースコードは公開されるべきです。サーバーサイドプログラムのソースコードは公開する必要がありません。

アップロードされるファイルのセキュリティ審査基準
- 外部データや動的データをプログラムとして実行するコードがあるか。
- ファイルの移動や削除は十分な安全対策があるか。
- 通信処理は安全か。受信される情報は何に使われるか。

常駐空間ゲーム

ゲームの一種。

常駐空間とは、MMOのいわゆるフィールドです。常に存在する空間で、プレイヤーが自由なタイミングで訪れて自由に行動します。そのため試合よりは冒険という印象が強くなります。

多くの場合常駐空間では明確な勝利条件が無く様々な活動が可能です。典型的には常駐空間ゲームとはPvEです。そのような環境において他のプレイヤーの存在は環境の一部です。プレイヤー動態に依存してその時々の状況が存在し、その中で何らかの条件を達成すると材料がもらえます。

C/S型のネットワーキングで提供されます。PvEベースです。PKがあっても問題ありません。常駐空間ゲームでも装備の販売が可能です。売上に応じて常駐空間ゲーム抽象ノードからエッジを獲得します。プレイヤーに与えられた材料は他のゲーム（常駐空間、レーティングゲームいずれでも）の装備を購入する際に使用できます。

PvE

PvEという用語はやや誤解されて広まっていると思います。私も昔誤解していました。良く対モンスターがPvEだと解釈されていますが、間違いです。PvEはプレイヤー対環境です。MMORPGに良くあるインスタンスダンジョンはプレイヤー対単純作業またはプレイヤー対キャラクター性能ベンチマークであり、PvEではありません。MMOの空間では他のプレイヤーが様々な活動をしています。例えばPKは環境の一部であり、PKがありうる環境で行動する事は環境との戦いです。レアモンスターを探して大勢のプレイヤーが奪い合う事もPvEです。MMOでは詐欺を生業とするプレイヤーも居たようですがそれもPvEらしい事です。ギルドが結成されたりギルド連合が作られたり勢力間の争いが勃発する事もPvEらしいことです。つまり、Player versus Environmentの字義通りですが、環境と戦う事がPvEです。インスタンスダンジョンやMOの試合は毎回同じ状況がセットアップされるのでPvEらしくありません。私はこの理解でPvEという言葉を用います。

PvP

PvPという用語はプレイヤー対プレイヤーであり、多くの場合試合を指します。バトルロワイヤル型のゲームはPvPとPvEの中間くらいのところにあると言えるかもしれません。

レーティングゲーム

ゲームの一種。

原則としてホスト型のオンラインゲームで制作者はサーバを用意する必要が無く、プレイヤー数の増加に応じてホストが増加するので自然とスケールします。（一応サーバ型も可能）

レーティングゲームの空間はその試合専用の一時的な空間です。サーバが無いので常駐的な空間を表現できません。 P2Pネットワークに記録される情報とプレイヤーのPCに保存される設定等を除けばレーティングゲームは独自の継続的なデータを蓄積していく事はできません。

ゲームの内容はPvPで、レーティングを高めます。

レーティングゲームの作者はTenyu基盤ソフトウェアを通してゲームを登録しますが、基盤ソフトウェアにそのゲームの対戦ルールについて記入します。チームの種類（ゾンビチーム、人間チーム等）や各チームの人数を設定します。

さらに、レーティングゲームのクライアントは試合結果について定められたフォーマットでTenyu基盤ソフトウェアに通知する必要があります。これは基盤ソフトウェアがAPIを提供し、ゲームクライアントがそれを呼び出します。それによってレーティングが更新されます。レーティングはP2Pネットワークに記録されます。

レーティングと試合数に応じて仮想通貨の分配額が決定します。

レーティングゲームは完全情報ゲームであることが推奨されます。非完全情報ゲームはホストによる不正行為を検出できないからです。

ゲームクライアントはTenyuから各プレイヤーの所有装備一覧を取得できます。プレイヤーは試合の中で所有している装備を使用できます。レーティングゲームは装備売上に応じてレーティング抽象ノードからエッジを獲得します。

試合終了時にプレイヤーの署名付きで試合結果がTenyuに登録されます。試合で不正行為があれば他のプレイヤーと報告する試合結果が食い違ったり、他のプレイヤーによって通報されます。

ゲームクライアントは試合のリプレイファイルを作成し、基盤に登録し、誰でも見れます。

ゲームの運営者は通報やリプレイファイル、試合結果の報告が食い違っている、そのような問題の発生率等からプレイヤーをBANします。（リプレイファイルと称してウイルスが送り込まれるリスクがあるので、リプレイファイルの検証を仮想マシン等で行うべきです）

ゲーム制作者はプレイヤーが不正行為を簡単に報告できるようゲームクライアントに機能を作成しておけます。例えば1クリックで試合IDや参加者一覧、リプレイファイル等についてゲームの運営者にメールを送れるようにする等。

本構想においてレーティングゲームの存在意義はユーザーに仮想通貨を与える根拠となる健全な試合を開催する事です。

微P2W

レーティングゲームは微P2Wであるべきです。具体的には以下を守る必要があります。

最初プレイヤーは仮想通貨が無く装備を買えないのであまり勝てません。そこでゲームは初心者向けに標準装備を用意してある程度戦えるようにします。
仮想通貨によって装備を購入する事はキャラクターの強化ではなく特殊化を意味します。プレイヤーはより多様な能力をキャラクターに与えるために装備を購入します。珍しい能力や多様な能力を持つ事は実質的に勝率を高める可能性がありますが、絶対的な優位ではなく対抗可能です。

レーティングゲームのチート対策まとめ

チート対策が成立しなければ持続可能なモデルと言えません。以下の対策があります。

ゲームクライアントはプレイヤーが他のプレイヤーの不正行為を見かけた時に簡単な操作で報告できるようにする。
試合終了後、各プレイヤーは他のプレイヤーが使用した装備についてその人が本当にその装備を所有しているかをゲームクライアントの処理を通じて自動的に検証する。基盤ソフトウェアは誰がどの装備を持っているかを知っているのでゲームクライアントと基盤ソフトウェアが連携すれば検証できる。問題があれば自動的にチートとして報告する。
各プレイヤー視点のリプレイファイルが記録されるので、問題が報告されたら検証する。再生するPCによって再生結果が異なるようではまずいからreproducibleなリプレイファイルが必要になる。それを達成できるクロスプラットフォームなゲームエンジンを探しているが、満足できるものを作るにはJDKがfat java案を採用する必要があるだろう。
Tenyuのユーザー登録は紹介制なので誰が不正ユーザーを紹介したか分かる。一般論として不正ユーザーはBANされても再度アカウントを作り直して違反行為を繰り返す場合があるが、Tenyuでそれはできない。不正ユーザーを繰り返し紹介している紹介者ユーザーがBANされるから。これによって不正行為をしないユーザープールが作られる。
試合のマッチングはランダム性があり対戦相手を自由に決めれないので結託系の不正行為が不可能。もし過疎な時間帯等でマッチングのランダム性が低かった試合はそれを意味するフラグが試合情報に立つので運営者はそのフラグが立っている試合に限定して調査できる。

暴言問題

ゲームでは良く一部プレイヤーの暴言が問題になります。この問題もやはりユーザー登録が紹介制である事によって徐々に暴言を吐かないユーザープールが作られていくと思います。

暴言のターゲットになるのはほとんどの場合新規プレイヤーです。既存プレイヤー全体が上達すると要求されるプレイヤースキルやキャラスペックの水準が高まり、新規プレイヤーが暴言のターゲットになる可能性が増します。

https://dpqp.jp/entry/post-5164

RMTを肯定する

従来のMMOでRMTは否定的にみられる場合がありました。本構想はRMTを肯定します。ただしアカウントの売買を否定します。オフライン秘密鍵の変更ができないので、アカウント売買はセキュリティ的に危険です。

ゲームにおける不正行為

何が不正行為に当たるかはゲームデザインに依存する場合があります。だから各ゲームの運営者が判断します。一般的に不正行為は競争の焦点が想定外のところになってしまう事が本質的問題です。例えばMMOでBOTが許されるならBOT開発が競争の焦点になり、ゲームを長時間プレイする必要が無く、即ちゲームを好きになる必要がありません。他にもチートが許されるならチートの方法を探したりチートツールを作る事が競争の焦点になり、プレイイングの上達が必要無く、やはりゲームを好きになる必要がありません。 そのゲームを好きな人がゲーム内で有利になる事がゲームデザイン及び運営の理想です。不正行為をする人が有利になるなら、大多数の健全なプレイヤーはそのゲームを好きにならない方が良いと思います。

アイテム

アイテムは全て取引不可です。ここでいうアイテムはTenyu基盤ソフトウェアが扱うアイテムです。各ゲームが独自のシステムでアイテムを扱う場合も考えられますが、それは各ゲームが自由に仕様を決定できます。

誰がどんな材料や装備を持っているかという情報はP2Pネットワークの全ノードに記録されます。

材料常駐空間でサーバーが任意の条件でプレイヤーに与えます。主に想定されるのはNPCの討伐等です。装備購入時に消費されます。
装備ユーザーは仮想通貨を支払って装備を購入し、ゲームを有利にします。購入に際し材料が必要な場合があります。装備は個体番号があり各ゲームは個体別の情報を作成できます。例えば使い込むほど成長するようなシステムが構築可能です。

Tenyuに登録されないアイテムもありえます。例えば常駐空間ゲームがその空間内のみで使用するアイテム、レーティングゲームが1試合の中でのみ使用するアイテム。そのようなアイテムは各ゲームが自由に仕様を策定できます。

マッチングサーバ

Tenyuは全てのレーティングゲームに共通のマッチングシステムを提供します。 レーティングゲームでは試合が開催されますが、そのマッチングをする必要があります。全体運営者が指定したノードがマッチングサーバを担います。マッチングサーバはタイムゾーン毎に設定されます。

マッチングサーバはレーティングに応じたランダムマッチを提供します。マッチングでは味方を選ぶ事は可能ですが敵を選ぶ事はできません。

ゲームクライアントはTenyu基盤ソフトウェアと通信してマッチング情報や参加プレイヤーに関する情報等を取得できます。試合への復帰は可能ですが、マッチング時点で参加者に含められて居なかったプレイヤーの途中参加は不可能です。

レーティング計算

Tenyuは全てのレーティングゲームに共通のレーティング計算を提供します。

SMEという計算方法があります。 http://www.tckerrigan.com/Misc/Multiplayer_Elo/ TenyuではSMEを拡張した計算方法を用います。その方法はほとんどあらゆる試合形式のゲームに適用できる汎用的なものです。ユーザーは各ゲームタイトル毎にレーティングを持ちます。チームメンバーの平均レーティングがそのチームのレーティングになります。チームのスコアのランキングでSMEが計算されます。SMEに提出するスコアは各ゲームが独自に算出します。例えばスコアという概念が無く勝ち負けしかないなら、勝者にスコア１、敗者にスコア０を指定します。試合参加者は各チームのランキングを報告します。チームのレーティング変動量がSMEで計算され、各チームメンバーのレーティングは全員その変動量だけ変動します。この方式はほぼ全ての試合形式のゲームに適用できると考えています。

ユーザー認証

TenyuはlocalhostのプログラムにWebAPIを提供します。P2Pネットワークで共有されている全情報を取得できます。例えば登録された素材のファイルパス、特定のユーザーの現在のIPアドレスとポート等です。 ※webapi構想は再検討中。IPCを通じた何らかのAPIが提供されるものの提供方法はより優れたものがありそう。

オンラインゲーム主軸モデル

画像、動画、音楽、文章、オフラインゲーム等ソフトウェアは海賊行為に晒されています。オンラインゲーム主軸モデルはオンラインゲームを軸とする経済モデルです。オンラインゲームは海賊行為に耐性があります。サーバーに特定のデータが保持される事、つまり承認情報とその周辺のユーザー動態が価値だからです。

オンラインゲーム主軸モデルは、クリエイターがオンラインゲームを盛り上げるような衛星作品を作り無料で公開し、それをオンラインゲームの収益力で収益化するというアイデアです。例えばオンラインゲームと同じ操作体系のオフラインゲームはそのオンラインゲームのチュートリアルとみなせます。実在のオンラインゲームを題材にした漫画を作る事も考えられます。あるいはプレイ動画等もオンラインゲームのプレイヤー動態に貢献する可能性があります。スターウォーズのMMOが作られましたが、有名な映画作品が先行していたことで大きな注目を受けました。オンラインゲームが衛星作品を収益化する理由はそこにあります。

Tenyuの構想ではオンラインゲームの売上から衛星作品の制作者に報酬を支払います。具体的には、相互評価フローネットワークでオンラインゲームから各種衛星作品へエッジを作成すれば報酬を与えれます。

つまりこのアイデアは、海賊行為に対抗するためにソフトウェアを無料で配布し、人々の価値観を海賊行為に耐性があるコンテンツであるオンラインゲームに移行させます。そして本構想によって収益化を図るというものです。このアイデアはビジネスモデルを海賊行為から守るだけでなく世界的にITセキュリティを改善します。海賊版ソフトウェアはウイルスが仕込まれている事が多いからです。

Tenyuにオンラインゲームを登録できますが、オンラインゲームの扱いは他の一般的なソフトウェアと異なり、レーティングゲームと常駐空間ゲームの抽象ノードから各オンラインゲームへのエッジがアルゴリズムによって自動的に作成されます。そして各オンラインゲームはそのプレイヤー動態に貢献していると思しきWebページ、例えばyoutubeの動画ページ等やプレイヤーのブログやwiki等にエッジを作成し、様々なものに報酬が与えられます。

衛星作品

オンラインゲーム主軸モデルを前提とし、動画、配信、漫画、フリゲ等を想定した概念で、 対象とするオンラインゲームへ人を誘導し盛り上げるような内容を持つ作品です。

ゲームの条件

不正行為がはびこったゲームはBANされます。ゲームがBANされると誰もそのゲームをプレイできなくなります。だから本構想におけるゲームはBOTやチートが現れにくいデザインであるべきです。例えば多人数対戦は単純なBOTが通用しません。複雑な判断が必要だし、不正行為が報告されやすいからです。逆に一人用ゲームはBOTが通用しやすく、報告もされにくいので、登録できません。

ゲームエンジン評価

私が各ゲームエンジンを評価した時の簡易メモです。別ファイルに私のソフトウェアに関する思想をまとめましたが、私の思想から、JVMベースのゲームエンジンを選ぶ必要がありました。

Unity。商業主義がきつい。SpatialOSが排除された。Tenyuも似たような立ち位置。ランキング上位。最大のエコシステムを持つ。 SpatialOSを排除した事はUnityが非創発ソフトウェアである事を示唆する。
UE4。ランキング上位。
Godot。ランキング上位。専門家が最も推奨する印象がある。
libgdx。開発力が低下中。2Dを主眼にしているが3Dとしても高い評価。BVHサポートが不明。C/C++/Javaで作成された。専門家が推奨する場合がある。
jME3。2019年4月のclosed issuesが18件。活発とは言えないが死んでいるわけでもない。アセットの読み込みやアニメーションのリターゲッティング処理が充実しておらず、可能なツールチェーンが乏しい。3Dを主眼にしている。アニメーションシステムを大幅に更新中。BVHサポートは中途半端で、古いアニメーションシステムに基づいて書かれている。専用のSDKがあるがアップデートされていない。 jmonkeyはその大規模な更新を始めたところでそれを担当していたコア開発者が非アクティブになった。おおむね、設計もプロジェクトの構成もサンプルコードもしっかりしている印象がある。その最大の長所はクロスプラットフォームな実行バイナリを作成できる事にある。Javaで作成された。
WhiteStormJS。クロスプラットフォームな実行バイナリという点で言えばJSも候補に挙がる。しかもJSの世界は活発で、ソースコードが公開され、ブラウザ上で実行されよりセキュアであるという長所がある。さらにTenyu基盤ソフトウェアはアセットランタイムになりうるので、多数のJSゲームでアセットランタイムを共有できる。しかしあらゆるブラウザでlocalhostとの通信ができるか分からない。JSにおいてブラウザ間互換性は完ぺきではない。WebRTCはブラウザ上のJSでP2P型オンラインゲームを作る事を可能にするらしい。しかし、P2Pソフトウェアとの連携、WebRTC、ブラウザ3Dゲームなど新しい事をたくさんやる必要があり、どこで問題が生じるか分からない。さらに、JSはWebAssemblyに代替される可能性がある。私の考察上、WWW及びJSの未来は怪しい。
lwjglエンジン一覧。恐らくほぼ全てのJavaゲームエンジン。http://wiki.lwjgl.org/wiki/Game_Engines_and_Libraries_Using_LWJGL.html#3D_Engines_and_Libraries 生きているのはlibgdx、jmonkey、Clydeだけ。チュートリアルがあり実用レベルなのはlibgdxとjmonkeyだけ。

最終的にjavafxベースでゲームまで表現しうる統合的なアプリエンジンみたいなものを作るべきかと思っています。ゲームと通常のGUIの差は何かについて考えると、相当に共通部分が見いだせるからです。単にGUIフレームワークというのではなく統合的なアプリ環境を作ろうと思っています。

タイトルを分ける

１つのオンラインゲームがレギュレーションが異なる試合を開催する事があります。本構想ではレギュレーションごとにタイトルを分けてください。複数のレギュレーションでうまくいくようにゲームバランスを調整することは困難なので、分ける方が破綻しにくいと思います。

ゲームの仕様凍結

多くの長寿ゲームで人気低下を防ぐため無駄にアップデートが試みられる事がありますが、避けるべきだと思います。そのようなアップデートは「もしかしたら人気を復活させれるかもしれない」というダメ元の試行錯誤であり、失敗した仕様がそのまま残ります。オンラインゲームはある程度のところで仕様を凍結すべきです。アップデートによってプレイヤースキルがリセットされる面があります。仕様が凍結されることでそれを防止できます。ある程度プレイヤーを得て膨大なプレイ時間（プレイヤー人月）を得たゲームは、むしろ仕様凍結によってゲームの寿命を延ばせます。プレイヤー側に蓄積されたプレイヤースキルがそのゲームの認知であり資本であるからです。

仕様凍結後、性能やセキュリティのためのアップデートか、例外的にプレイヤー動態の変化などでゲームバランスが崩壊する危機に瀕した場合のみアップデートします。

アバター

VRM形式をサポートします。特にサポートされるのはvroidです。 BVH形式のボーンアニメーションをサポートする予定です。アバターのモデルファイルは基盤ソフトウェアの個人用領域に登録されます。 BVHファイルは基盤ソフトウェアに共用素材として登録されます。

ゲームを好きになる

オンラインゲームではゲームのどの部分を好きになっても問題無いと言えるゲームデザインが理想です。さもなくばプレイヤープールは脆いものになります。

コンテンツ消費型ではコンテンツを好きになってもすぐにそのコンテンツで遊ばなくなります。プレイヤーはコンテンツ消費型ゲームにおいて消費されていくコンテンツを好きになってはいけません。
仕様凍結されないゲームはテクニックを磨いても仕様変更で無駄になる可能性があります。プレイヤーは仕様凍結されないゲームにおいてビルドやスキルや戦術等を好きになってはいけません。
アバターが自由じゃないゲームは自分のキャラクターを好きになれるか分かりません。
P2Wはそのゲームに時間をかけた人即ちそのゲームが好きな人が負けて金を払った人が勝つゲームである事を意味します。プレイヤーはP2Wのゲームを好きになってはいけません。微P2Wは可能かもしれません。

P2P技術

※以下、技術的内容

P2P技術による仮想通貨は誰もが全体のデータを持っていて透明性がありデータの遷移が追跡可能であるという透明性があります。さらに、独自のP2P技術によるユーザー全員の投票を通じた意思決定機能があり、全体運営者を選出できます。C/S型サービスは管理者をユーザーが選出する事ができませんが、Tenyuではそれが可能になります。投票プロセスや結果は作者である私や全体運営者ですら改ざんできません。その投票技術は世界的な電子投票を実現しうる重要なものです。

Tenyuはプロセッサ証明と分散合意と同調処理という独自のP2P技術によって桁違いの性能と省電力をセキュリティを保ちつつ実現します。このようなP2P技術への想定される攻撃手段これらサンプルコードを順番に読み、いくつかの用語解説を読めば分かると思います。

分散合意模擬動作。異常排除型と平均型 https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/DistributedVoteSample2015.java

分散合意によって不正値を信じ込んだノードが正常値へと回復する動作を示す。異常排除型 https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/DistributedVoteSample2018.java

演算量証明コア部分。いかにしてCPU以外での演算を防止するか。このような動的な問題生成が可能なのは分散合意がもたらす主観信用で良いという性質がノード毎の問題を可能にする事による。参照：ストーリー https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/CPUProvementTestSample2018.java https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/CPUProvementSample2018.java

分散合意とプロセッサ証明の相補性のサンプルコード。異常排除型だが信用によるダミーノードの排除は平均型にも応用可能 https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/ProcessorProvementSample2019.java

ノード、エッジという言葉

以降P2P技術に関する項目におけるノード、エッジという言葉はP2Pネットワークのノードやエッジです。相互評価フローネットワークのノードやエッジではないので混同しないよう注意してください。相互評価フローネットワークはP2P技術と無関係です。P2Pノード、P2Pエッジと言っていたら相互評価フローネットワークと区別するためにあえてそう呼んでいます。 P2Pネットワークはごく標準的な意味のP2Pネットワークですが、相互評価フローネットワークはP2Pネットワークで共有されるDB上のデータです。

独自用語

P2P技術 P2Pプラットフォーム確立のための技術。確立以降の多彩な機能はこの文脈で無関係。
- 客観、客観DB、統一値、合意された値
- 主観
- プログラム及び定数当然ながら全ノードが同じP2Pソフトウェアを実行し、そこには定数などがあり、それも全ノードで同値である事が期待できる情報の一種と言える。これも統一値と呼ぶ場合があります。P2PソフトウェアはTenyu基盤ソフトウェアと呼んでます。
- 分散合意
- プロセッサ証明
  - 主観的な信用
- 選挙
  - ターン
  - 全体運営者選挙によって選出され、共同主体の管理者になり、共同主体からエッジを作成します。その他Tenyu全体の設定値などを決めたり、BANの最終判断をします。ここのmanagerListが全体運営者一覧です。複数居て、それぞれ影響力割合が設定されています。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/ObjectivityCore.java
- 同調処理
  - 整合性情報
  - 一斉更新
  - 客観DB不整合検出、ハッシュツリー客観DBが不整合である事が判明した時、どの部分が不整合を起こしているのか効率良く特定する必要があります。そこを特定できたら近傍から正しい値を取得して自分の客観DBを上書きします。不正な値を教えられても客観DB全体のハッシュ値が分かっているので正しいハッシュ値になるまで繰り返し同調処理が行われます。このHashStoreクラスはハッシュツリーを提供し、不整合箇所を効率良く特定できます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/db/store/satellite/HashStore.java
- 近傍の自動追加各ノードは近傍一覧を持ちますが、P2Pソフトウェアが自動的にP2Pネットワークを探索してアドレス交換を実施し、近傍を追加します。最初近傍は少しも信用されておらず局所的多数決において主張値をほぼ無視されます。プロセッサ証明を通じて徐々に信用が高まります。他に友人のノード等を手動で追加する事もできて、そのようなノードは演算量証明無しで強く信用します。このような演算量証明以外の信用ソースを持つという性質は分散合意ベースだからこそ可能になります。主観に基づく信用強化が可能です。分散合意ベースで信用は局所的多数決において使用されるだけだから可能です。自分が友人として追加した近傍について、つまり主観情報について、他のノードやP2Pネットワークから何らかの証明を得る必要はありません。ここのperiodicGetAddressesが近傍の自動追加を行います。主観情報は他のノードに伝わる事が無いと言いましたが、細かい事を言えばこれはその例外です。自分が知っているノードのアドレスを他のノードに教えるという動作をします。これによってP2Pネットワークを探索可能になります。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/subjectivity/Subjectivity.java
- 近傍の定期削除各ノードは独自の近傍一覧を持ちますが、それはレイテンシの悪さや同じ時間帯にオンラインにならない等の理由で定期的に削除され、近傍一覧は洗練されていきます。ここのrankingAndRemoveがそれを行っています。近傍から定期的に演算量証明を通じて信用値を獲得しないと近傍関係を削除されてしまうので、ダミーノードに対して常に排除圧がかかっています。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/subjectivity/UpdatableNeighborList.java
P2Pプラットフォームが確立しさえすれば実現性に問題が無い多彩な機能この文書に書かれている事は大まかにいうと、P2P技術（P2Pプラットフォームの確立過程及び継続的保護システム）と、そのP2Pプラットフォームで何をするかという事に分かれます。というのは、一度P2Pネットワークで共有される改ざん困難な客観DBというものが実現されると、そのDBを利用して様々な事が可能になりますが、その応用面の話は多彩でキリがないので分けて捉えて置く必要があります。例えば以下がそのような応用面になります。
- ユーザー登録紹介制です。 Userクラス https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/individuality/User.java User登録メッセージ https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/request/gui/right/user/UserRegistration.java
- 相互評価フローネットワーク
  - 相互評価フローネットワークのノード様々な種類があり、種類毎に管理者になる方法が違います。ソースコード上ではSocialityがそれで、客観DBに記録されます。SocialityにWalletがありそこに仮想通貨残高がある事を確認してください。これはUserだけでなく共同主体やWebページ等が仮想通貨残高を持ちうるという事で、いわば法人のような非人間が残高を持ちうるということです。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/sociality/Sociality.java
    - 共同主体ノード選挙によって全体運営者になる事で管理者になれます。相互評価フローネットワークの根本にあるノードで、ここから経路ができてフローが流れ込むと仮想通貨分配を受けれます。
    - ユーザーノードユーザー登録をすると自動的に作成され、そのユーザーが管理者になります。
    - Webノード誰かが未登録のURLについてURL証明をするか、他のノードが未登録のURLにエッジを作成した場合に作成されます。
      - URL証明任意のWebページをTenyuのシステムに登録し、相互評価フローネットワーク上のWebノードを作成できます。https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/middle/takeoverserver/urlprovement/URLProvementServer.java
    - レーティングゲームノードレーティングゲームが登録された時に登録され、その登録者が管理者になります。
    - 常駐空間ゲームノード常駐空間ゲームが登録された時に登録され、その登録者が管理者になります。
  - エッジ貢献を記述します。例えばフリーソフト→ライブラリというようなエッジが作られます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/sociality/Edge.java
- 仮想通貨分配
  - 無責任支払い
- 連合型MMO
  - レーティングゲーム https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/individuality/game/RatingGame.java
  - 常駐空間ゲーム https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/individuality/game/StaticGame.java

他に私が用いる可能性のある独自用語はここに書かれています。programmingEnvironment.md

主観

各ノードの手元でのみ扱われる情報。即ち攻撃者がアクセスする事すらできず改ざんのリスクは一切ありません。基本的に他のノードと共有されない。例えば近傍の各ノードをどれくらい信用するかという情報は主観として扱われる。 subjectivityパッケージに主観系のクラスがまとめられています。ここにP2PNodeやP2PEdgeがある事を確認してください。それらクラスは相互評価フローネットワークと無関係です。P2Pプラットフォームの確立過程、つまりP2P技術が駆使される段階では主観系のクラスが主に使用されます。 https://github.com/lifeinwild/tenyu/tree/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/subjectivity

客観

P2Pネットワークの全ノードで共有されるDBを客観とか統一値と呼ぶ場合があります。各ノードが客観全体を持ち、同値です。ここに仮想通貨残高や相互評価フローネットワークのエッジ等重要な承認情報が記録されます。客観を高速更新できる事及び改ざんされないようにする事がこれら一連のP2P技術の主旨です。ソースコードのAdministratedObject系のクラスが相当します。例えばUserはそれを継承しているので客観DBに記録される事が分かります。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity/AdministratedObject.java objectivityパッケージに客観系のクラスがまとめられています。 https://github.com/lifeinwild/tenyu/tree/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/objectivity

局所的多数決

自分の近傍と何らかの事柄について多数決をする。分散合意はこれを繰り返す。局所的多数決は、平均や中央値を作成する場合もあるし、通常の多数決のように一致ベースで各選択肢の票数を集計する場合もあります。選挙は平均（異常値の排除等もあるが）で、同調処理は一致ベースの集計で最大得票の選択肢を採用します。これのinteractionメソッド等は局所的多数決の実装例です。なお局所的多数決はもともと相互作用関数と呼んでいたので、メソッド名がinteraction(相互作用)という名前になっています。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/vote/PowerVoteStatement.java

参考画像：過剰近傍攻撃

主観的な信用

主観的な信用は、P2Pネットワークにおいて各ノードが他の各ノードへの信用値を自分だけが使う値として持ち他ノードへ伝播させないというもの。分散合意及びプロセッサ証明及びその相補性から、主観的な信用値を作り出すだけで良いというところに問題が帰結させられ、うまく問題が解決されている。近傍のノードをどれくらい信用するか、つまり分散合意の局所的多数決でその近傍の主張値にどれくらいの票数を与えるか、を決定する数値である。このため信用値は分散合意（P2Pネットワークで重要な合意された値を作成する）への影響力である。信用は大部分プロセッサ証明を通じて増加する。（他に手動で友人のノードだから信用するといったことを設定する等も考えられるがそれは周辺の雑多な発想でありP2P技術の説明ではない）分散合意が局所的多数決のみでP2Pネットワーク全体での同調（合意された値の作成）ができるという性質をもたらすので信用は主観で良いという事になります。主観一般の改竄不可能性（どうやって他ノードがただ自分だけで持っている情報を改ざんできるか？）及び分散合意における主観的な信用で良いという性質（局所的多数決）が重要です。 getImpressionはそのノードへの主観的な（自分からの）信用を返す。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/subjectivity/P2PEdgeBase.java

整合性情報

客観はUserStoreやSocialityStoreなど様々な多彩な機能のためのストアを持ちますが、各ストアは自前のハッシュツリーを持ち、各ストアの最上位ハッシュ値を集めた整合性情報を近傍とやり取りします。それによって客観DB全体の整合性をチェックできます。近傍と現在の整合性情報について局所的多数決を行い、正しい整合性情報（各種ストアの最上位ハッシュ値）を特定し、自分の客観がずれていたら修正します。不整合を起こしている箇所はハッシュツリーによって効率良く特定されます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/middle/catchup/Integrity.java

全体的なイメージ

各ノードは普段近傍と客観DBについて各々のタイミングで随時同調処理しています。これによって客観DBがノード毎にまちまちになることが防止されています。だから一部のノードだけが客観DBを更新してもすぐに近傍の影響で元の状態に戻ります。だから一斉更新をします。全ノードで一斉更新すれば客観DBが古い状態に戻されてしまう事がありません。 TenyuのP2P技術の客観DBの更新性能はこの一斉更新の性能で決まります。

※メッセージ拡散及び一斉更新は2種類の実装方法があり、現在のネットがブロードキャストの方法を提供していないので、ブロードキャストに頼らない方法を採用しています。

一斉更新の時、同調処理は短時間停止しています。一斉更新が終わったら同調処理が再開します。

そうして全ノードで客観DBが同値なままP2Pネットワークが客観DBを更新していきます。

以上が基本的な、普段の処理です。

TenyuのP2Pネットワークは定められた日時に選挙を実施して全体運営者を選出します。選挙は従来技術で存在しなかったと思います。この機能は同調処理や一斉更新という普段の処理ではなく、たまに実施される重要な全体での合意（全体運営者選出など）のための機能です。基本的な普段の処理は上段で説明が完了しています。選挙は普段の処理ではありません。しかし同調処理と選挙は、背景にある技術的アイデアはプロセッサ証明と分散合意であり、同じです。ただ同調処理は各ノードのタイミングで随時行われるのに対して選挙は全ノードがタイミングを合わせて一斉に行います。選挙は高性能ではありませんが、極めて堅牢で、その意味（たまに重要な全体での合意を行う）から頻繁に行う必要があるものでは無く高性能は要求されません。

予め各ユーザーは自分のGUIに自分が支持するユーザーを設定しておきます。これは選挙のたびに設定する必要は無く一度設定すれば継続的に使用されます。なぜ選挙が必要か？P2Pネットワークの全体の決定を誰に委任するかという問題があるからです。もし全体の決定ができなければ実現できる機能が制限されます。例えば共同主体からのエッジを誰が設定するか？ある種の特権を扱えないとそのシステムで実現出来る事は限られます。

プロセッサ証明

ダミーノードを排除してP2Pネットワークの堅牢性を高める技術。演算量証明を発展させた概念で、8時間置き2分間程度の特定の時間帯にのみ動作すればよく（この点で演算量ではなくプロセッサを証明していると言える）、即ちビットコイン系と比較して桁違いに省電力であり、問題は各ノード毎に動的に作成された専用のものを解くのでCPU以外で効果的に演算量を証明できず、その問題の動的作成から回答までの一連の情報処理的性質から近傍の近傍数の制限まで行える（ここの説明が難しい）。続き

ストーリー

この流れを模擬的に示すサンプルコード

最初、全ノードは互いを全く信用していません。つまり分散合意の前提であるダミーノード排除ができておらず、選挙や同調処理ができません。全ノードで同値な客観を維持しながら仮想通貨残高など価値ある承認情報を作成、更新していく事もできません。ただし相互にアドレス情報を交換してP2Pネットワークを形成します。アドレス交換は誰かに特権を与えるとか利益を与える事ではないので、信用を必要とする事ではありません。

そうしてP2Pネットワークを作ってみても、まだ誰も互いを信用していないので、自分は仮想通貨をこれくらい持っているぞと誰かが言い出しても一切信用されず意味がありません。この段階では客観DBを全ノードで同値にする方法が存在しない、全ノードで統一された情報が無いということです。（ソフトウェア中に定義された定数等を除けば）

以下、各ノードが互いの信用値をどのように高めていくかという事、それでなぜ全体が堅牢になるか、どのように全体で共有される情報（客観DB＝仮想通貨残高等の重要な承認情報を格納するもの)を作るかを説明します。

全体的な流れ。なおソースコードは本番用とサンプル用があり説明では混在しているがどちらにもほぼ同じコードがある。ここに示す流れは本番用コードではProcessorProvementSequence#setupStatements()に現れている。

同時刻（例えば予めソフトウェアに定められている）に各ノードはランダム値を各近傍に送信
近傍から届いたランダム値を連結し問題作成情報（ProblemSrc）を作成 allRndStr変数が連結されたランダム値。
そこからハッシュ値を作成 ProblemSrcクラスのgetHash()
ハッシュ値から問題関数を作成例えばこのサンプルコードの756行目でハッシュ値から問題関数を作成している。ここで問題関数がこの時近傍が作成したランダム値に依存しているので、問題関数を予め計算しておく事が不可能だったとそのランダム値を作成した近傍の元で証明される。予め計算しておけない事の証明は定められた時間内で演算するしかないことを意味し、省電力となる。
引数探索。各ノードは近傍から届いたランダム値から作成された問題関数を解く。 CPUProvementクラスのparallelSolve()やsolve()が実行されるということ。本番用コードではRandomStringStatementクラス#interaction()の後半がこの動作をする。
回答作成＆近傍に送信 Solveクラスやそれを含んだResultクラスが作成されランダム値を送信してきた近傍に送信される。本番用クラスではAnswerStatementクラス#send()がこの動作をする。なおここで送信される回答は全ランダム値を元に作成された問題関数への回答であり、各近傍毎に作成された問題を解いたのではなく全近傍のランダム値を連結した値に対する問題を解いた事になる。
回答検証＆近傍への信用値付与 CPUProvementクラスのverify()が実行されるということ。そして回答が正しいなら主観的信用を付与する。これによってプロセッサの存在が証明されダミーノードへの排除圧となる。本番用コードではAnswerStatementクラスのverifyNode()がこの動作をする。ここの182行目で自分が送信したランダム値が全ランダム値に含まれているかチェックしている。これによって予め計算しておくことが不可能だった問題（たった今作成された予測不可能な問題）をその近傍が解いた事が自分の下で（主観的に）証明される。

達成されている重要な性質。

予め計算しておくことが不可能な問題を解くことで、特定の限られた時間帯にのみ演算量証明が行われる。実際8時間おき2分間しか演算量証明しないで済む。従来技術と比較して劇的に省電力となる。
ハッシュ値から作成される問題関数は、およそGPU等でアクセラレーションできない内容になっている。なおその生成ロジックは随時変更可能であり今後も継続してハードウェアアクセラレーションを回避していける。即ちプロセッサ証明は実質的にCPUの存在を証明している。
1つの問題関数に回答するだけで全近傍において信用量を獲得できます。これによって近傍数が増加しても引数探索（演算量証明）が増加しなくなります。もし近傍数の増加に比例して問題を解くのが難しくなると、P2Pネットワークがエッジ不足で脆くなります。
問題作成情報が近傍からの全ランダム値を含む事から、近傍の近傍数をある種証明的に知ることができます。全ランダム値の長さを１ランダム値の長さで割れば近傍数になります。これを過大に見せかける事はできますが過小に見せかける事はできません。もしそれをやると解くべき問題関数の数が増えるので不正に信用を獲得するという目的には適いません。これによって過剰近傍攻撃が防止されます。
ハッシュ値から問題関数を作成できる事で、当然ながらハッシュ値は様々な情報から作成できるので、任意の情報から問題関数を作れます。これによって近傍からの問題作成情報を総合して1つの総合された問題作成情報を作りそこから問題関数を作る事が可能になります。
ノード毎に毎回異なる問題を解くことになり、回答のパターンをあらかじめ網羅しておくようなことはできません。
特定の条件を満たした出力を探すという引数探索をもって演算量証明することで、正答を見つける労力に比べて検算が簡単になります。

A。基盤ソフトウェアはプロセッサ証明を実施する日時を定数として持っています。プロセッサ証明はある種の演算量証明で、しかしいつでも受け付けられるわけではなく定数によって決められた時間帯しか受け付けられないので、8時間おきに2分程度の処理が発生するだけです。この点で四六時中演算量を投入し続ける従来のP2P技術より省電力です。さらに、この点で演算量を証明する（何時間でも演算して量で勝負する）というよりもプロセッサを所有している事（特定の時間帯における演算ペース）を証明していると言えます。その日時が来ると全ノードは一斉に近傍にランダム値を送ります。さらにTenyuの通信では基本的に送信者の公開鍵も分かるので、送信者公開鍵とランダム値と受信日時を対応付けれます。多数の近傍から受け取ったランダム値から問題作成情報が作成されます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/ProblemSrc.java 問題作成情報とはプロセッサ証明の問題関数を作成するための情報です。問題関数は、任意のハッシュ値から作成できて、それに正しい回答を作成する事でプロセッサ性能が伴っている事を証明できます。

各ノードが自分だけの問題（近傍から送られたランダム値に依存した問題）を解くので、ブロックチェーンのように全ノード共通の問題を解くわけではありません。

B。各ノードは通常多数の近傍を持っているので多数のランダム値を受け取ります。受け取った全ランダム値から「総合された問題作成情報」を作り、そこからハッシュ値を作り、ハッシュ値から一意に定まる問題関数を作成します。総合された問題作成情報は後で出題者（ランダム値を送ってきた近傍）に送信されますが、出題者の元で「自分が送信したランダム値が入っているから今初めて確定した問題だ」と分かります。ここのinteractionメソッドは近傍から多数の問題作成情報を受け取り、それらを総合して1つの問題作成情報を作成し、 139 CPUProvement.parallelSolve から呼び出されるCPUProvementクラスは問題作成情報からハッシュ値を作成してハッシュ値から問題関数を作成し、それの返値が特定の値になる引数を探索します。その探索された引数が回答情報になります。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/ProblemSrc.java

ここの222 generateProblemがハッシュ値から問題を作成します。そのメソッドのコメントに書かれているのは作成される問題関数の性質。hは元とするハッシュ値。cNはクラス名。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/CPUProvement.java このように近傍から寄せられた多数の問題作成情報からただ1つの総合された問題作成情報を作りそこから問題関数を作り、つまりただ1つの問題関数を解くだけで全ての近傍において演算量証明ができるということは、近傍数の増加に反比例して1ノードあたりの演算量証明が低下するという事が無くなります。もし1つ1つの近傍毎に異なる問題を解いていたら近傍を増やすのが難しくなり、近傍数が制限され過ぎると孤立するノードを多発させP2Pネットワークを脆弱にします。とはいえ問題を簡単にし過ぎるのもP2Pネットワークがダミーノードに攻撃されるリスクを高めます。演算量証明のために近傍数に深刻な制限をもたらしてはいけないということで、全近傍でまとめて演算量証明できるというアイデアが必要でした。

回答を作成できたら近傍に送りますが、ここの182で回答の確認をしています。相手が送ってきた回答が相手が計算した問題に対して正しい事と、その問題が自分がその時作成したランダム値から作られた事を確認できれば、その回答がその時計算された事が分かり、相手がプロセッサを伴っている事が分かります。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/Answer.java

問題関数を作る時問題作成情報に任意の値を加える事ができます。結局ハッシュ値を作れればいいのと、問題作成情報のランダム値に近傍が送信してきたランダム値が含まれてさえいればその近傍の元で有効であり、他の情報に依存してはならないという制約はないからです。例えばコード中でparallelNumberという変数がありますが、近傍からただ1つランダム値を受け取るだけで、そこに勝手に番号を加えてハッシュ値を変化させ、各ハッシュ値からそれぞれ問題関数を作成し、多数の問題関数への回答を計算しまとめて回答する事で信用を大幅に高める事ができます。問題作成情報に問題の番号を回答者側で勝手に加える事で複数の問題関数を作成できるということです。計算能力に余裕があるノードは多数の問題を解いてその分多くの投票権を獲得できます。

問題関数は引数を取ります。その出力が特定の範囲になるような引数を探索します。引数探索より引数の検算の方が簡単にできるので、解くのは難しく確かめるのは簡単という事になります。つまり回答の検証処理は楽になりボトルネックにならなくなります。ここの228から検証処理があります。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/Answer.java

問題関数はAにおいてランダム値に依存している事から予め作成しておく事ができません。即ち予め回答を計算しておく事もできません。そして問題を解いたら近傍に回答として送信します。このとき回答に総合された問題作成情報を含めます。・・・C 1つ1つの近傍に全近傍が送ってきたランダム値を全て含めて送信するという事です。そうするのは、回答者が「総合された問題作成情報」に対してのみ回答を計算したからです。つまり1つ1つの近傍が送ってきた問題作成情報に対して直接回答を計算したのではなく、それらを総合した問題作成情報に回答を計算したので、自分が解いた問題を回答に含める必要があるので、総合された問題作成情報を回答に含めます。なお総合された問題作成情報は1つ1つの近傍から受け取った問題作成情報のランダム値を連結したもの（全ランダム値）を含みます。回答を受け取ったノードは、その全ランダム値の中に自分が送ったランダム値が含まれている事を確認することでその時回答が計算された事を確認し、その回答がその問題に対して正しい事を確認します。このとき、AとBから、その回答を送ってきたノードは今その計算をして回答をしたのだと分かります。そうして初めて全く相互に信用していなかったノードが互いを少し信用します。 231でスコアインクリメント、115でノードnが今回獲得したスコア、138でノードの信用更新。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/Answer.java

なお信用は継続的に、徐々に変化していくものです。ここの168 updateProcessorScoreの実装が示すように、新たに獲得した信用によって既存の信用値が徐々に変化していきます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/subjectivity/P2PEdgeBase.java 102 getImpressionの返値はノードの信用を大部分決定します。ここの284 creditメソッドで最終的なノードの信用値を取得できます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/subjectivity/P2PEdge.java

Cの重要性について。回答に含められたランダム値の長さによって、近傍の近傍数を知る事ができて、その近傍数は過少報告が防止されています。近傍の近傍数をある意味で証明的に取得できるという事です。 187から近傍の近傍数を確認しています。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/processorprovement/Answer.java Bは1つの問題関数を解くだけで複数の近傍において信用が得られる事を意味します。そうであれば、多くのノードの近傍となる事でP2Pネットワークにおいて大きな信用を獲得できます。しかし、Cによって、回答を受け取ったノードは回答者がいくつの近傍に対してまとめて回答を送信したかが分かります。 ”近傍の近傍数がある意味で証明的に分かる”という事です。近傍数を過大に見せる事はできても過小に見せる事はできません。過少に見せるとは即ち回答に含められた問題作成情報のランダム値の長さを短くするという事ですが、そこを少しでも変えるとハッシュ値が変化して全く違う問題になります。仮に問題作成情報のランダム値を真ん中で切って2つに分けたとします。するとどちらも元のハッシュ値から全く変わってしまい、問題関数も大幅に変化します。そして2つの問題関数に適切な答えを見つけなければならなくなります。ランダム値を複数に分ける事は「多数のノードに対してまとめて回答を作成する」という有利さを捨てている事を意味します。なお検証者（ランダム値を送ってきた近傍＝出題者＝検証者）は自分が送信したランダム値が含まれているかを確認するので、もし回答者が回答を無関係なノードに送ってもそこにそのノードが送ったランダム値は含まれておらず、信用は得られません。この方法によって膨大な近傍を持つ事によってP2Pネットワークにおいて過剰な投票権を獲得するという攻撃を防げます。（ちなみに私はこれらP2P技術を2015年に発明していたのにこの近傍の近傍数の証明的取得ができるという性質に2017年まで気付かず自分の中で没案にしていました）

このようにすると他のノードがプロセッサを持っている事を確認していけて、それによって信用を徐々に高めていきます。分散合意において信用されたノードの影響力が強化されます。つまりプロセッサの性能に応じて投票権が得られているという事です。するとダミーアカウントを排除できます。プロセッサ証明の必要性はただただダミーアカウントへの排除圧を作るためです。1台のPCで大量のダミーノードを実行してもプロセッサ性能が限られているのでこのような方法の元で他のノードから信用値を獲得する事はほとんどできません。ダミーアカウントが排除されると健全な分散合意が可能になり、同調処理や選挙が可能になります。プロセッサ証明の主旨は1個のプロセッサで大量に実行されるダミーアカウントを排除する事です。

もう1つ特筆すべき事は、このような方法論による選挙の実施は国境を超えてネット全体において可能であるという事です。

ところで、近傍がプロセッサを持っている事を信用できたとして、それはあくまでそのノードの元でのみ有効な主観的な信用であり、その信用を他のノードに伝播する術はありません。「あのノードはこれくらい信用できる/プロセッサ性能を伴っている」と言っても他のノードは信用しないという事です。信用の伝播は生じません。では全ノードが他の全ノードの信用を自力で確認する必要があるかというと、そうではありません。分散合意というアイデアによって局所的多数決のみで全体での多数決と同等の事ができるという状況にあるので、近傍の信用さえ分かれば良いのです。

つまりここに書いた一連の流れで分散合意の局所的多数決からダミーノードを排除できたということで、分散合意の準備が整ったという事になります。

分散合意が可能になれば即ち選挙と同調処理が可能になったという事です。

選挙で全体運営者を選出できて、選出されたノードは自動的にいくつかの権利が与えられ、P2Pネットワーク上で特別な役割を果たせるようになります。投票によって選出された人が決定した事だからという理由で各ノードはその決定に従います。全ノードが他のノードを一切信用していない状況からここで初めて全体の意思決定に従う素地が完成します。そして全体運営者がメッセージ受付サーバを指定する事で客観DBの更新が開始します。

同調処理は随時客観DBを多数派と同値なものにします。

想定される攻撃手段

過剰近傍攻撃
ダミーノード
近傍関係が無いのに勝手に主張値を送るスパム攻撃（近傍関係が無い事や信用値がない事等によって排除可能）

これらの問題がどう解決されているか？サンプルコードで示されています

ダミーノード

健全に演算量証明できないノード。典型的には1台のPCで大量に実行されたノード。ダミーノードが分散合意において影響力を持つようでは同調処理が操作されて客観は改ざんされてしまうし選挙は操作されてしまう。プロセッサ証明による票数の差別化によってダミーノードは解決される。

過剰近傍攻撃

局所的多数決で極端に多くの近傍を持つ事によって分散合意の収束値を操作しようとする行為。ストーリーが示すように近傍の近傍数の証明的取得によって解決されます。

分散合意

「P2Pネットワークの全ノードで共通の改竄困難な情報を持つにはどうすればいいか」という問題を「局所的多数決においてダミーノードや過剰近傍攻撃を排除するにはどうすればいいか」という問題へ帰結させるアイデア。

新入りノードが正しい値を獲得できるか？＞近傍から正しい値を局所的多数決の結果として取得する。なおこれによってDB全体のハッシュ値（ハッシュ木による）を取得すればDBの同調処理が可能になります。
攻撃者が不正値を主張したらP2Pネットワークが不正値に染まらないか？＞いくつか考えられる攻撃手段があるがそれぞれ解決されている
用途は？＞分散合意の種類

独自の発明であり、「近傍との局所的多数決を繰り返すだけで全体で多数決をした場合と同じ情報が各ノードの手元に現れる」という性質があり、局所的多数決をするだけで良くなるから各ノードはただ近傍への主観的な信用を持つだけで良くなる。（このように問題を別の所に帰結させて全体がうまく解決されます）信用の伝播をしなくていいので攻撃者が改ざんしうる情報を元に信用を作るという事が無い。サンプルコードで分散合意の性質を確認できます。分散合意は平均（選挙型）、同値型（異常排除型）があるし、全ノード一斉にやる場合もあれば任意タイミングでやる場合もあります。この短いコードは分散合意の局所的多数決が全体の多数決と同じ結果になる事を示します。私は分散合意を思いついた時実際にサンプルコードを書いて結果を確認するまで確信が得られませんでした。シミュレーション的なコードであり因果関係を頭の中で追いきれないからです。 https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/DistributedVoteSample2015.java https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/DistributedVoteSample2018.java

次のコードは基盤ソフトウェアの実装における分散合意のコードです。これ以外に同調処理も分散合意です。getTurnCountMaxは20回局所的多数決を繰り返す事を示しています。interactionは局所的多数決の実装です。PowerVoteは選挙（複数の選択肢に合計値が1.0になる実数値をつけ全ノードの投票権が差別化された平均を得る処理）です。それは各選択肢の重みづけという事であり、PowerVoteさえあれば様々な意思決定が可能になります。全体運営者候補AとBが居てAが0.7、Bが0.3の影響力を持つ、というようなある種の影響力配分が可能です。あるいは最大値を獲得したAのみが特別な権限を持つようにする事もできます。PowerVoteさえあれば一通りのアンケートや意思決定的な処理ができるということです。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/vote/PowerVoteStatement.java

分散合意の種類

分散合意は2種類あります。異常排除型平均型

このような事が種類を分けます。

開始時点の状態はどんなものか。（攻撃者が関与せずとも当然に）ノード毎にまちまちか、それともほとんどのノードが同じ値か。
終了時点の状態はどんなものか。全体の平均値等を求めるのか、開始時点の多数派の値に少数派が一致するだけでいいのか。
全ノード一斉に局所的多数決をするのか、各々のタイミングでやるのか。

選挙は開始時点の状態（誰にどの程度投票するか）がノード毎に当然にばらばらで、終了時点では平均値に収束（全ノードで一致）し、全ノード一斉に局所的多数決をします。

同調処理は開始時点の状態は６～９割程度のノードで一致していて（客観DB）、終了時点ではほぼ全ノードで一致し、各ノードばらばらのタイミングで同調します。

平均型

分散合意の種類の1つ。選挙型と言っていた事も。開始時点で各ノードがまちまちな値を主張し（攻撃者というわけでなく当然に思い思いの値を主張する）、終了時点でそれらの平均的な値に収束する。これは全体運営者の選挙等で使用されます。

異常排除型

分散合意の種類の1つ。開始時点でほとんどのノードが正しい値（＝多数派の値）を持っていて、開始時点で不正値を持っていた少数派が終了時点で正常値（開始時点の多数派の値）になれば成功とするもの。例えばDB全体のハッシュ値はほとんどのノードが正しい値を持っていて、新入りノードや攻撃者だけが間違った値を持っているので、DBの同調処理は異常排除型です。

分散合意とプロセッサ証明の相補性

その相補性を認識できればTenyuのP2P技術をほぼ理解できたということになります。

分散合意

「ダミーノードに弱い」という欠点
「局所的多数決のみで良い」という長所

プロセッサ証明

「近傍ノードの信用しか算出できない」という欠点
「近傍についてダミーノードを排除できる」という長所

これらが相補的に組み合わさり、P2Pネットワーク全体での多数決（同調処理や選挙）が実現されます。

私が分散合意と呼んでいるものは、近傍との局所的多数決を全ノードが繰り返す事で全体で多数決をした場合と同じ結果が各ノードの元に現れるというP2Pネットワークの現象です。局所的多数決において信用が高いノードの主張はより重くなります。その差別化された票数はプロセッサ証明で作られた信用に応じて変わります。局所的多数決をするだけで良いから信用を伝播する必要がありません。近傍の信用だけ分かればいいのです。それで信用で投票権が差別化された局所的多数決が可能です。

ダミーノードが排除される事でユーザーにおける実際の多数派が信用（主に演算量）においても多数派になります。そこにおいて多数決が実現されるとは即ち少数派意見が排除されるということであり、「悪意あるノードは少数派である」という前提が成立するなら不正な改ざんが阻止されるということです。

その相補性によって全体運営者の選出投票などネットワーク全体での意思決定や、任意のDBの保存及び更新ができる客観DBの同調処理が可能になります。

選挙

分散合意の種類の1つで、平均型でターンがある。開始時点で各ノードはまちまちな値を持ち、終了時点でそれらの平均的な値に収束し、全ノード一斉に局所的多数決します。

全体運営者の選出や任意の内容のアンケート等ができます。これらP2P技術によって、選挙を不正に操作する事は技術的にできません。 PowerVoteがその実装です。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/vote/PowerVoteSequence.java

選挙による全体運営者選出によって、メッセージ受付サーバ等の特別な役割を担うノードをP2Pネットワーク全体で認可できます。なお全体運営者は選挙で選ばれた時に自動的にメッセージ受付サーバの候補に加えられます。

選挙は、P2Pネットワークが特別な権限を一部ノードに担わせます。 P2Pネットワークを使って何をするかを考えた時、特別な決定を下せる全体運営者の存在は助けになります。例えば誰をBANするか等の決定、全体の方針決定、各種設定値などは全体運営者が担う他ありません。選挙で選出された特権ノードを受け入れる事はP2P分野の可能性を広げます。そしてこの選挙は堅牢であり誰も恣意的に改ざんできません。ネットワークの過半数のノードが悪意ある改ざんをしない限り。

ここに選挙の1実装があります。このPowerVoteという機能は、複数の選択肢についてそれぞれの選択肢の影響力をP2Pネットワーク全体で決定します。その中で最大の影響力となったものを採用してもいいし、上位いくつかの選択肢を採用してもいいし、全体運営者の候補を選択肢としてそれぞれの影響力を算出する事にも使えます。 133で信用が取得され、145で信用が低い意見は除外されます。ここで信用はプロセッサ証明によって得られた近傍の信用です。 170で次のターンの自分の主張値が設定されます。このような局所的多数決を20ターンも繰り返せばP2Pネットワークがどれほど巨大でも全体で多数決した場合と同じ結果をどのノードにおいても持つ事になります。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/vote/PowerVoteStatement.java

メッセージ拡散

一斉更新においてある程度まとまったメッセージリストを一斉に反映するという話がありましたが、その要素であるメッセージの拡散処理は2種類の実装方法が考えられました。

純粋P2P型
メッセージ受付サーバ型

メッセージ受付サーバ

メッセージ受付サーバは客観DBを更新するための電子署名つきメッセージを受け付けるサーバで、一旦そこで溜め込まれてから数万件まとめてP2Pネットワークに拡散される、というようになっている。インターネットがブロードキャストを提供するならメッセージ受付サーバを無くして耐障害性を飛躍的に高めれるが、現状のインターネットの機能だとどうやらメッセージ受付サーバを置く方が合理的という事になる。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/middle/takeoverserver/usermessagelist/UserMessageListServer.java

ターン

ターンとは全ノードがタイミングを合わせて局所的多数決を進める事です。

分散合意は局所的多数決を数回繰り返すが、平均型では各ノードがベストエフォートで最速実行するのではなく、ターンがあり、速く通信が終わったノードは次のターンの開始時間が来るまで待機する。ここの285 sleepUntilでそのターンの終了時間が来るまで待機します。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/TurnBaseMessage.java

あるいは分散合意のサンプルコードでもターンがあります。 https://github.com/lifeinwild/tenyu/blob/master/src/sample/java/bei7473p5254d69jcuat/tenyu/sample/DistributedVoteSample2015.java

平均型においてターン概念が必要な理由は他のノードの処理を待つ必要があるからです。各ノードが他のノードを待たずに最速で実行するようでは例えば「遅いノードが3ターン目に入った時速いノードは既に全20ターンを終えて局所的多数決を締め切っている」という問題が生じて値が収束しないからです。

ところが同調処理等の異常排除型の分散合意ではターン概念が不要になります。異常排除型では「正常動作していれば当然どのノードも正しい値を持っている」という前提があり、僅かな異常値を排除するという処理になる事、それと同調処理における一旦ずれても再度同調すればいいというタフな性質がターン概念の排除を可能にします。異常排除型と平均型は全ノードの初期状態について前提が違います。同調処理では客観DBの整合性を扱うので、ほとんどのノードが正しく一斉更新を重ねていれば開始時点で正しい値を持っていて当然なので初期主張値がほとんどのノードで一致しています。同調処理ではターン概念が無くとも性能及びセキュリティが成立します。

一斉更新

一斉更新は客観DBの同調処理下における客観DBの高速な更新方法です。客観DBは主に一斉更新によって更新されます。

同調処理によって全ノードで客観DBが同値に保たれますが、逆にそのせいで一部のノードが客観DBを更新するだけでは即座に古い値に巻き戻ります。だから客観DBの更新は「一斉更新」が必要になります。一斉に客観DBを更新すれば巻き戻りません。

そしてもう1つの要点は、客観DBの内容である重要な承認情報は大部分が誰かユーザーの電子署名を根拠に作成・更新された情報だというものです。例えば仮想通貨の送金は送金者の電子署名があれば堅牢という事になります。プロフィールの更新はそのユーザーの署名があれば堅牢という事になります。つまり本人または特権を担当している者の電子署名がついたメッセージを受け取ると各ノードはそれを受け入れて客観を更新します。これはUserRightRequestIクラスが扱います。客観DBに含まれる情報の中でこのようなユーザーの権利的ではない情報は、現在の全体運営者情報など選挙を通じて作成される情報です。

ということで、一斉更新における客観DBの更新は、同値なUserRightRequestの一覧を全ノードが持ち、同時に反映するという事です。これがその一覧を表現するクラスです。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/right/UserMessageList.java これが反映処理のインターフェースです。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/request/UserMessageListRequestI.java

一斉更新ではある程度メッセージを溜め込んでから一斉に反映します。反映タイミングは全ノード同時でなければならず、実際2分に1回しかありません。さらにメッセージリストは全ノードで同値である必要があります。メッセージが一部のノードにしか届いていないという事があってはならないという事です。

一斉更新はこのあたりのコードに書かれていますが、同調処理とのタイミング問題の解決等極めて複雑です。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/communication/mutual/right/ObjectivityUpdateSequence.java

TenyuのP2P技術が従来技術と比較して桁違いに高性能である（ノードの性能をほぼストレートに発揮できるというP2Pネットワークとしてほぼ上限のスループット）という事になるのは、主に一斉更新によるものです。（その背景には同調処理による客観DBの同調などがあって一斉更新は成立しているし、同調処理の背景には分散合意やプロセッサ証明がある）

同調処理

分散合意の種類の1つ。

同調処理は統一処理といっていたこともあった。客観DBを全ノードで同値にするための処理で、各ノード各々のタイミングで局所的多数決が行われます。同調処理は異常排除型で、ターンが不要。

セキュリティ上同調処理でターン概念が不要であるという認識はTenyuのP2P技術において最も捉えるのが難しいと思います。しかもそれは一斉更新を裏で支える重要な仕組みです。P2Pネットワークでノードがオンラインになったりオフラインになったりする描像、そしてオンラインになったノードが客観遅れを自分のタイミングで修正していく描像を捉え全体として多数派の客観が同値なまま推移する描像を捉える必要があります。

なお同調処理を通じて客観が更新される（近傍と同調される）のは一部の遅れたノードが追いつくための補助的な処理であり、客観は主に一斉更新によって更新されます。同調処理の存在意義はオフライン状態から復帰したノードが遅れを取り戻すためにあります。ネットワーク全体が何らかの攻撃に晒されて客観DBの不整合が大規模に生じた場合でも同調処理によってP2Pネットワーク全体で客観DBが同値になります。

cathcupパッケージに同調処理系のクラスがまとめられていますが、このあたりは極めて複雑な並列処理です。 https://github.com/lifeinwild/tenyu/tree/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/middle/catchup

客観DBは全ノードで同値である事が期待され、仮想通貨残高など重要な承認情報が記録されるところなので、ノード毎に異なってはいけません。そのため定期的に同調処理が発生して客観DBを同値にします。 Tenyu基盤ソフトウェアのDBはHashStoreという機能によってDB全体のハッシュ値を高速に取得できます。 https://github.com/lifeinwild/tenyu/blob/master/src/main/java/bei7473p5254d69jcuat/tenyu/db/store/satellite/HashStore.java そして近傍ノードと現在のDBのハッシュ値について局所的多数決を行いながら、もし不整合があれば食い違っている部分を効率良く特定できます。この同調処理における局所的多数決でもプロセッサ証明で得た信用が使用されます。そうすると、もし同調処理において嘘のハッシュ値を近傍に伝えてP2Pネットワークの多数のノードを騙そうとした場合、まず多数のノードで信用を得る必要があり、それにはP2Pネットワークの過半数のノードの合計プロセッサ性能を上回るプロセッサ性能を長期間用いる必要があります。長期間用いる必要があるのは近傍ノードへの信用が継続的に蓄積されるものだからです。

同調処理は極めて入り組んだ並列処理です。同調処理関連のクラスはcatchupパッケージにあります。 https://github.com/lifeinwild/tenyu/tree/master/src/main/java/bei7473p5254d69jcuat/tenyu/model/release1/middle/catchup

同調処理も一種の分散合意とみなせます。プロセッサ証明によって助けられた局所的多数決の繰り返し、それによる全体で多数決した場合と同じ結果になるという共通の性質があります。ただし各ノードそれぞれのタイミングで随時行われているという点が特徴的です。

古い説明＿分散合意

分散合意が達成する技術的意義は、悪意あるノード等の影響で間違った情報を持たされたノードが正しい情報へと回復する事である。定期的に分散合意が行われる事で、悪意あるノードはその間隔の時間内に過半数のノードに不正値を持たせなければ、一旦不正値を持たせる事に成功したノードも分散合意のたびに正常値へと回復してしまう。過半数のノードに不正値を持たせれたら恣意的改ざんに成功するが、分散合意によってそれに厳しい時間制限がつく。分散合意において正しい値とは多数派の値である。まず基本的に想定される状況を説明する。プログラムが正常か、値が正常かという2つの観点でノードを分類できる。プログラムと値が正常なのは通常のノードである。プログラムが正常で値が異常なら、悪意あるノードの攻撃によって間違った値を信じ込まされる等したノードである。プログラムと値が異常なら、悪意あるノードである。プログラムが異常で値が正常というケースは考えにくく、一旦この議論において考慮する必要は無いだろう。それぞれ正正、正異、異異ノードと呼ぶ。分散合意は、正異ノードを正正ノードに回復させる処理である。分散合意の挙動を示す模擬コードがあるが、５５％が正正、２５％が正異、２０％が異異ノードである場合に、ほぼすべての正異ノードが正正ノードへと遷移し、ネットワークが正常性を取り戻す事を示している。４５％ものノードが不正値を信じている状況からでも回復できる。中央管理ノード無しで分散的に正常値へと統一できる。短く言えば、p2pネットワークを多数派意見に統一できる。過半数のノードが正正ノードであるという前提が成立している限り、分散合意は正常な値へと統一を押し進める。定期的な分散合意によって、攻撃者は分散合意の間隔以内にネットワークの過半数のノードに不正な値を信じ込ませる必要がある。分散合意によってほとんどのノードが正常値を持つので、新規参加ノードはいくつかのノードに値を問い合わせて多数決をすればほぼ１００％の確率で正しい値を取得できる。 分散合意のネットワークを回復させる性質は、以下に説明する相互通信と相互作用関数の繰り返しによって発生する。全ノードが一斉に近傍リストの全ノードに情報を送ると、各ノードは自分を近傍リストに持つノードから、つまり自分を矢印の先とするノードから情報を受け取り、典型的には多数のノードの近傍リストに入っているから、多数の情報を受け取る。そのような通信を相互通信と呼び、相互通信される情報を相互通信情報と呼ぶ。各ノードは相互通信情報を受け取ったら、近傍から来た全ての相互通信情報を引数として次の相互通信で自分が送信する相互通信情報を作る処理を実行するが、その処理を相互作用関数と呼ぶ。相互通信情報と相互作用関数は、分散合意において収束する性質が必要である。典型例はＹｅｓ／Ｎｏを意味するｂｏｏｌｅａｎで多数決が行われたり、数値型で平均を算出したり、ハッシュ値で多数決が行われる。模擬コードにおいて多数決や平均が収束することが実証されている。多数決さえできれば、P2Pネットワークは情報を統一できる。大規模なデータを効率良く統一する方法についてDBの統一処理として後述する。分散合意において相互通信と相互作用関数は複数回繰り替えされ、繰り返しの中でP2Pネットワークを飛び交う相互通信情報は徐々に多様性を失い収束していく。それは悪意あるノードによって騙されて不正値を持たされていた善意のノードが正常値へと回復している事を意味する。なぜなら多数派の値へと収束するのであり、過半数のノードが善意のノードであるという前提があるからである。中央機関的なノード無しで、つまり全体の集計無しで分散的処理のみで多数派の値へと収束できる事は技術的に特筆すべきことである。なお後述するプロセッサ証明というアイデアによって、投票権が差別化された多数決が行われる。差別化とはノードによって多数決における票数が異なるということである。プロセッサの性能が高いほど票数が増える。プロセッサの性能に応じた投票権というアイデアはダミーノードを排除し、分散合意の堅牢性を完成させる。ダミーノードは典型的には1台のコンピューターで実行された膨大なノードである。もし、ダミーノードが分散合意の多数決に通常のノードと同等に影響するなら、悪意ある人が膨大なダミーノードを作って多数派となり、多数派が正常値を持っているという前提が破綻する。分散合意によって統一された値は統一値である。統一値は値のある種の性質であり、ほぼ全ノードで同値である必要があり、恣意的改ざんがされていないと考えられる値である。分散合意で作成される以外では、ソフトウェアに予め設定されていたり、分散合意によって選出された特別な権限を持つノードの電子署名つきメッセージがP2Pネットワークで拡散され各ノードが受け入れる事で作成される。このような作成方法のいずれもがほぼすべてのノードで同じ情報を持つ事ができて、恣意的改ざんがされていないと考えられる。作成方法によってなぜそれが統一値だと考えられるかは異なる。分散合意の収束値がなぜ統一値とみなせるかは模擬コードを理解するしかないだろうが、分散合意は1か所に集計して全ノードで多数決をした場合とほぼ同じ結果になるので、過半数のノードが善意のノードであるという前提を受け入れるなら恣意的改ざんがされないと考えられる。ソフトウェアに予め設定されている値は改造しない限り全ノードで同じであり統一値であると考えられる。分散合意によって選出された特別な権限による設定は、恣意的改ざんをしないと信用できるノードをそのような権限の担当者として選出するのであり、恣意的改ざんが無いと考えられる。十分な統一に必要な相互通信回数はノード数と近傍数と相互通信情報と相互作用関数で変化するが、せいぜい20回程度であり、世界的Ｐ２Ｐネットワークであっても多様な用途を見出せる程度の性能が見込める。分散合意の回復的挙動は模擬コードで示されているが、その模擬コードはシミュレーション系のコードなので読むだけでは分からないので、実行して確かに多数派への統一が起きている事を確認してください。５５％の正常なプログラムかつ正常な値のノード、２５％の正常なプログラムかつ不正な値のノード、２０％の不正なプログラムかつ不正な値のノードという条件下で、その第二グループがほぼ全て第一グループへと復帰することが確認できる。

古い説明＿プロセッサ証明

分散合意をダミーノードから守る方法を説明するが、その方法をプロセッサ証明と呼ぶ。近傍のプロセッサの性能を証明的に確認し、プロセッサ性能に応じて投票権を設定する。ランダム値から問題関数が作成されるが、ランダム値を送ったノードを出題者または検証者、ランダム値を受け取ったノードを回答者と呼ぶ。実際、全ノードが近傍にランダム値を送り、全ノードが近傍からランダム値を受け取り、全ノードが出題者かつ回答者になるが、説明のためそのような言葉を用いる。投票権は分散合意の相互作用関数における票数であり、差別化された多数決等が実現される。投票権は各ノードの手元で実行される相互作用関数における影響力を意味するだけなので、主観値である。どのノードがどのノードにどの程度の投票権を認めたかという情報は、その投票権を認めたノードだけが知っていればいい。自分の元で実行する相互作用関数からのみ参照される情報だからです。プロセッサ証明による投票権の差別化が無ければ、膨大なダミーノードを作りネットワークに参加させることで、過半数のノードが善意のノードであるという前提が崩れます。分散合意の回復的性質は失われ、膨大なダミーノードの管理者は恣意的改ざんが可能になります。プロセッサ証明はそれを防止します。プロセッサ証明の開始日時と終了日時はソフトウェアに予め設定されていて、全ノードがその時間内に行います。その時間内しか回答を受け付けません。その時間は1日10分以下で十分です。もしそのような日時の制限が無く回答を受け付ける時間がノード毎にばらばらだったら、回答を受け付けているノードを探して回答を送る事でいつでも投票権を稼げるので、投票権獲得競争が生じたときに24時間フル稼働するノードが現れます。そして、問題関数はその開始日時と同時に作成され、予測不可で、予め計算しておくことが出来ない。予め計算しておけるなら、やはり投票権獲得競争が生じると24時間フル稼働するノードが現れます。問題関数が今作られた事を証明する方法について。プロセッサ証明の開始日時が来たら、全ノードが自身の近傍にランダム値を送信する。つまり各ノードは近傍から多数のランダム値を受け取る。近傍からの多数のランダム値を全てハッシュ関数に入力して１つのハッシュ値を作る。そうして作られたハッシュ値と近傍からの全ランダム値をランダム値を送ってきた各近傍に返すと、そのハッシュ値がまさに今作られたことが近傍において証明される。ハッシュ関数は入力値が僅かでも異なると全く違う出力をするが、自分が今送ったランダム値に依存したハッシュ値が返ってきたからである。各近傍は全ランダム値を受け取っているので、自分の元でハッシュ関数を実行してみることで確かにそのハッシュ値になると確認できるし、全ランダム値に自分が今送ったランダム値が含まれている事を確認できる。その時点で、そのハッシュ値が今作られた事が近傍において証明される。そして、後述するが、ハッシュ値から問題関数を一定の方法で作成できて、その作成方法はハッシュ値と問題関数がほぼ１：１対応しているので、同様な方法で問題関数も今作られた事を証明できる。つまり自分がさっき送ったランダム値が無ければ作成しえない問題関数について回答を送ってきたのなら、今計算が行われたのだと自分だけは確信できて、プロセッサ証明は自分の元で使う投票権という値を作成するだけなので、自分の元で証明されれば十分である。そして回答が正しければ、投票権を設定し、相手のノードは分散合意における影響力を強める。ダミーノードは演算量を出せないからほとんど投票権が得られない。検証者は、プロセッサ証明を通じてダミーノードによって自分が恣意的操作される可能性をほぼ排除できる。善意のノードがダミーノードのリスクを排除するから、ひいてはP2Pネットワークが堅牢になる。さらに問題関数は、ハッシュ値に応じて処理内容が作成され不規則なので、いつも同じ出力になるなどではなく、出力も予測不可である。つまり、予め計算しておくことが不可能な問題関数を実行して回答を返す事で、まさにその時間内にプロセッサを稼働させたことを証明できる。予め計算しておけないことと回答受付時間が全ノード共通でかなり限られている事と合わせて、その時間外にプロセッサを稼働させて投票権を増やす方法が無く、投票権獲得競争が発生したとしても、その時間内しかフル稼働しないで済む。後述するが問題関数の計算量は調節可能なので、十分に難しくすれば、膨大なダミーノードは問題関数の回答をほぼ送れない。ダミーノードは典型的には1台のコンピューターで実行された大量のノードであり、1ノード当たりのプロセッサ性能が乏しいからである。さらに、００１３で述べるように、各ノードはハッシュ関数への入力に任意の情報を加える事で問題を多数作成できて、プロセッサ性能に応じて多数の問題を同時に解いて多数の回答を送る事が可能で、善意のノードは1ノードだけで大きな投票権を獲得する。つまり、ダミーノードによる分散合意の収束値の操作は防止される。
なお問題関数の元となるハッシュ値の元となる情報を問題作成情報と呼ぶ。添付したプログラムのProblemSrcが相当する。
なおプロセッサ証明はアクセラレーション困難であることが望ましい。特殊なハードウェアで高速に計算できてしまうと、一部の人が大きな投票権を獲得し、分散合意で強い影響力を持ち、恣意的改ざんの可能性が高まるからである。プロセッサ証明の問題関数はCPUが最も効率良く計算できるような関数であることが望ましい。

古い説明＿プロセッサ証明において近傍の近傍数を証明的に確認する方法

プロセッサ証明は一度の回答処理で多くの回答者に対して回答を作成できて、まとめて投票権を獲得できる。もしソフトウェアを改造し著しい数のノードの近傍に入る事に成功すれば、過剰な投票権を獲得できる。しかし、近傍の近傍数を証明的に確認できるので、近傍数に応じて与える投票権を弱めればその脆弱性は無くなる。
回答は問題作成情報を含んでいるが、そこに全ランダム値が入っている。回答者が複数の出題者から受け取った全てのランダム値である。１つの近傍が送るランダム値の長さが固定だと、全ランダム値の長さを1つのランダム値の長さで割る事で、回答者が回答を送り得たノードの数が分かり、それが近傍の、つまり回答者の近傍数である。回答者は全ランダム値を長くする事で近傍数を不正に増やす事はできるが、それは回答者の投票権を弱めるだけで意味が無い。回答者は実際に回答を送ったノードの数よりも少ない近傍数を伝える事ができれば投票権を不正に強める事ができるが、その方法は無い。誰か検証者の送ったランダム値を全ランダム値から削除すると、検証者は全ランダム値に自分が送ったランダム値が含まれているかを確認するので、削除された検証者は投票権を与えず、回答者が得られる投票権が増すわけではない。送られてきたランダム値を２つのグループに分ければそれぞれの全ランダム値は短くなるが、それは2回分の回答処理を必要とし、計算量が2倍になり、正当な演算を伴わずに投票権が得られるわけではない。結局、全ランダム値の長さから得た近傍数は、無駄に増やす事はできるが、減らす事はできないので、過剰に多くのノードの近傍になると言う手段による不正な投票権の獲得は防止される。

古い説明＿分散合意を通じた全ノードにおけるDBの統一方法

ここでDBは統一値を蓄積したものである。実際のDBは非統一値も記録されうるが、非統一値は従来の情報処理と何ら変わらず、説明の必要が無い。
各ノードは自分のDB全体のハッシュ値を相互通信情報として分散合意を通じて統一値を決定する。最初の自分のハッシュ値が最終ターンのハッシュ値つまり統一値と同値でなければ、自分のDBが多数派のDBに一致していない事を意味するので、キャッチアップ処理を行う。キャッチアップ処理は、DB全体のハッシュ値が分散合意という堅牢な方法で既に決定している事と、DB各部のハッシュ値を信用できない方法で決定してDBを構築していっても最終的に全体のハッシュ値が一致していなければ間違っている事が分かる事から、DB各部のハッシュ値を簡単かつ効率の良い方法で決定する。DBをいくつかの部分に区分し、各部で現在のハッシュ値を作成し、複数の近傍にDBの各部のハッシュ値を問い合わせて、返された複数のハッシュ値で多数決をして各部の正しいハッシュ値を決定し、ハッシュ値に一致するデータを任意のノードから受信し、その部分について自分のDBを上書きし、それを繰り返して自分のDB全体のハッシュ値を統一値のハッシュ値に一致させる。この方法はDB全体のうち多数派と差異がある部分のみ上書きする。DBの区分の方法はこのアイデアの主旨ではなく様々考えられるが、大きすぎればDB全体のほんの一部が異なるだけでDB全体を更新する必要があり、小さすぎれば各部のハッシュ値の確認が膨大な回数発生する。
P2PネットワークはDBの統一を定期的に実行する事で確実に多数派においてDBの状態遷移が一致する。誰も多数派を恣意的に操作する事はできないので、このアイデアによってP2Pネットワークは仮想通貨残高やオンラインゲームのアイテム所有情報等価値ある情報を保存できるようになる。つまり恣意的改竄が困難な情報の保存先になる。
DBの統一は、DB全体のハッシュ値が統一値として得られているので、DBの各部のハッシュ値やデータを近傍から得るプロセスは堅牢性を気にする必要性があまり無い。最終的にDB全体のハッシュ値が統一値と同値かを確認し、間違っていれば近傍を修正して再び更新を試みるからである。

古い説明＿定期的なＤＢの統一処理下における任意のノードが任意のタイミングでＤＢの更新を起こす方法

定期的なDBの統一処理のせいで一部のノードがDBを更新してもすぐに元に戻ってしまう。しかし、情報を統一し保存することができても、更新できなければ実用性が無い。P2Pネットワークで堅牢に保持統一されている情報を各ノードがある程度自由なタイミングで更新する方法を説明する。基本的アイデアは全ノードが一斉にDBを同様に更新するというものである。多数派の値が変わるので、DBの統一処理で巻き戻されない。
基本的なアイデアは、まず更新内容を記述したメッセージを作成し自分の元で蓄積しておき、メッセージ受付サーバに送る。メッセージはそれを作成したユーザーの署名がついているので、メッセージ受付サーバが腐敗したとしてもできることは送信されたメッセージの無視だけで、存在しないメッセージを捏造する事はできない。メッセージ受付サーバは定期的に、例えば1分毎に、蓄積されたメッセージリストをP2Pネットワークに拡散する。このとき、メッセージ受付サーバの署名がある事、メッセージリストに含められた各メッセージの署名や内容が妥当であることを各ノードの元で確認する。そして予め全ノードが同時にメッセージリストを用いてDBを更新する。そのタイミングは日時情報が統一値であればいいので、統一値を作成する方法に示したいずれかの方法で作成しておける。
メッセージ受付、拡散、反映は全て常時行われる。受付において作成されているメッセージIDをNとすると、拡散されているのはN-1で、反映されているのはN-2である。

純粋P2P型のみでメッセージ拡散するには

Tenyuは現状P2Pネットワークの全ノードへの効率的な送信方法が無い事から、純粋P2P型のみによるP2Pプラットフォームを断念しました。ハイブリッド型になっています。

とはいえメッセージ受付サーバ等シングルポイントとなっているノードで障害が発生してもネットワーク全体は停止せず純粋P2P型と同等の耐障害性を持つという性質が維持されています。特別な役割を担っている一部のノードが故障するなどして突然動作を停止しても、全体運営者投票（純粋P2P）が定期的に行われ新しい全体運営者が自動的に新たなメッセージ受付サーバの候補となるので、代わりのメッセージ受付サーバが純粋P2P的に選出されるという事で、メッセージ受付サーバが停止してもP2Pネットワークは停止しません。メッセージ受付サーバはただP2Pネットワークの客観DB更新のスピードを速めるため、ネット負荷を軽減するためだけに存在し、そこで障害が発生すると一時的に客観DB更新が停止しますが、新たな候補を選ぶ事で復旧できます。つまり純粋P2P型は最も重要な客観情報（全体運営者）を作るために使われ耐障害性を与え、準P2P型はほとんどの客観更新を行いスピードを与え、相補的な関係にあります。

以下これに関連して考えた事を書いておきます。

基本的に考えるのは、様々なノードから生じるメッセージがあり、1メッセージ400バイトで3-100万メッセージを1分間にP2Pネットワークの1-10億程度の全ノードに行き渡らせれるかという問題です。簡単に考えてみると、既にそのメッセージを持っているノードに再度送信するような無駄な通信が多発する事が分かります。そのため、恐らく実質的なデータ量の20倍程度の送受信が各ノードで発生します。

ノードは任意のタイミングでオフラインになったりオンラインになったりするので、固定的な連絡網を構築するというアイデアがあまり通用しません。連絡網というアイデアはP2Pネットワークをメッセージが拡散していくときの経路が重複しないようにする（前述した「無駄な通信」を防ぐ）面がある。任意のノードから生じるメッセージを拡散させなければならないというのも連絡網の設計を難しくします。通常の連絡網は情報の発生元を限定できます。

重複送信を防ごうとメッセージに送信済みノード一覧のような情報を記録するとメッセージのサイズがでかくなりすぎるので本末転倒となる。

10Gbps回線が普及すれば多少無駄な通信があっても（純粋P2P型でも）まともな性能を出す事が出来ますが、その場合でも準P2P型なら10倍以上のスループットを達成できます。

もし広域への一斉送信（ブロードキャストまたはプロセスを検索してのマルチキャスト）がハードウェアレベルで可能ならこの問題は解決されます。
例えばTVの電波のような地上波または衛星波の広域無線送信をPC用途で使用する事が考えられる。しかしその送信装置が多重化されていなければ耐障害性が落ちてしまう。

もう１つの解決策は「無駄な通信の排除（フィルタ）」をハードウェアレベルでやること。

P2Pプラットフォームは全ノードに情報を行き渡らせるために近所のPCとの通信が多発する面があるので、各PC（またはルータ）が無線を使って直接近所のPCと通信できると効率がいい。それについて考えると自発的なインターネット網の構築という思想も見える。例えば各PCが無線機能を備えて近所のPCと相互に通信し、さらに通信をリレーしてインターネット網を構築するなど。

他にグループのネットワークというアイデアを考えた事がある。各ノードは同じグループの全ノードを知っていて誰かがメッセージを受け取ればグループ内全体に送信するとか。低レイテンシなノード（近所のPC)でグループを作る、グループ内の全ノードが同時にオフラインになる確率はある程度低いので、グループを単位とした連絡網というアイデアが考えられる。とはいえこのアイデアもあまり良くなさそうだった。グループの安定性とグループ内の重複受信が問題として残る。

あるいはAIで適応的に近傍関係を作り丈夫な拡散経路を作るか、などと考えた。

低レイテンシグループは地理的に近い位置に居る事を意味し地域的な障害で同時にオフラインになるリスクがある。すると連絡網がそこから先途絶する事になる。連絡網を耐障害性が高いようある程度多重化したりすると効率は低下する。

私はP2Pプラットフォームの可能性を信じているし、そのために効率的なブロードキャスト（全ノードへの情報送信）能力が必要になると思うが、インターネットのこのあたりの問題がどう解決されるか分からない。とりあえず現状マシな方法を採用するしかないということでメッセージ受付サーバを採用している。

P2Pによる存在日時証明TSA

ここで自身が作成したソフトウェアについて自身が制作者であると証明したい者を証明者と呼ぶ。他人のソフトウェアについて自身が制作者であると捏造したい者を攻撃者と呼ぶ。
Tenyu基盤ソフトウェアはDBを一斉更新する直前にメッセージ拡散するが、その時、証明者の存在日時証明のメッセージを攻撃者が真似て、同じハッシュ値の存在日時証明のメッセージをネットワークに流すかもしれない。この攻撃は特にメッセージ受付サーバがやりやすい。

P2PネットワークではC/Sと同じ方法では存在日時証明を実現出来ない。

その問題を回避するための手順を示す。
証明者は証明対象のファイルのハッシュ値を秘密鍵で署名しその署名を含めたメッセージを作成する。実際の公開日時証明の前にそのメッセージを予め客観に反映させる。この時点ではその署名がどんなハッシュ値に対するものか分からず、捏造（同じハッシュ値に対する署名を同時にネットワークに流す）は不可能。さらに捏造を試みる価値（どんなデータに対するハッシュ値か）も不明。・・・A
Aによって署名が客観に登録された事を確認したら、Aによって先行して登録されている署名データのIDとその対象ハッシュ値と署名者のユーザーIDを含むメッセージをネットワークに送信し、客観に登録する。これが存在日時証明となる。
攻撃者がメッセージを捏造したとしてもAの登録者が優先される。

P2Pによる存在日時証明TSAその２

他の方法として、P2Pプラットフォームの全ノードで証明しなくてもいくつかのノードで証明できればいいなら、C/Sと同様の方法で他のノードにTSAを提供させればいい。

公開日時証明

Tenyutalkと呼んでいるWWWを置き換えうる仕様を念頭に設計している機能があり、それを用いて制作物を読み取った人が署名を残す事でその署名リストをもって公開日時証明とみなせます。

オフライン秘密鍵

まず基盤ソフトウェアを起動するとオフライン鍵、PC鍵、モバイル鍵が作られます。各鍵は公開鍵と秘密鍵のペアになっています。オフライン秘密鍵は最も秘密にすべき情報で、PC鍵とモバイル鍵を更新する場合に使います。普段使用しないので、オフライン端末に保存するべきです。

P2Pソフトウェアにおけるスキーマエボリューションの解決

エンドユーザーのPC上でP2Pソフトウェアが実行される場合、数ヶ月ぶりに起動する人や、起動中に突然電源を切ったりプログラムを強制終了する人を想定する必要がある。しかし、DBを用いるソフトウェアはバージョンアップに伴いDBについて古いスキーマから新しいスキーマへの更新処理が発生し、その処理の重さは記録されたデータ件数に依存し、しばしば非常に重たい。しかも数ヶ月ぶりに起動したユーザーのDBは直前バージョンではなく過去の任意のバージョンである可能性を想定する必要がある。
その問題の解決策を示す。関連する議論がソースコードのIdObjectStore.javaにも書かれている。
DBはスキーマレスのKVSにして、オブジェクトをシリアライズして記録する。クラスはバージョンアップされていくが、P2Pソフトウェアに過去の全てのバージョンのクラス定義を含める事で古いシリアライズされたオブジェクトを読み出せるようにする。プログラムのリリース毎に専用の名前空間を用意する。典型的には<...>.release1.<...>、<...>.release2.<...>など連番部分を作る。例えば
org.organizationX.app1.release1.db.ClassA
org.organizationX.app1.release1.db.ClassB
というクラスがあり、次のリリースでClassAがバージョンアップされて
org.organizationX.app1.release2.db.ClassA
が新しいClassAとして作成され、古いClassAはrelease1に残り、ClassBは更新されていないのでrelease1にだけ存在する。
ちなみに、IDE上でアップデート対象のクラスを最新の名前空間に移して、IDEによる参照の更新を起こし、さらにそのファイルを元の名前空間にコピーする事で確実に参照を更新しつつ古いクラスを残せる。
DBに記録されるオブジェクトのクラスは必ず１つ前のバージョンからのバージョンアップメソッドを実装する。そしてオブジェクトを読み出した直後に次のバージョンがあれば更新する処理を書く。その更新処理は、次のバージョンのクラス定義がある限り次々とバージョンアップされるという連鎖的なバージョンアップである。例えば、クラス定義をバージョンアップするたびにオブジェクトの読み出し箇所に以下のように追記していく。例。
if(loadedObject instanceof org.organizationX.app1.release1.db.ClassA){
loadedObject = org.organizationX.app1.release2.db.ClassA.VersionUp(loadedOject);
}
if(loadedObject instanceof org.organizationX.app1.release2.db.ClassA){
loadedObject = org.organizationX.app1.release10.db.ClassA.VersionUp(loadedOject);
}
ここでrelease2から10にバージョンアップされるのはrelease3-9においてクラスAがバージョンアップされなかった場合を想定している。
このようなアイデアによってエンドユーザー環境のDBに過去のどのバージョンのデータが記録されていても読み出されたタイミングで必ず最新版のデータにアップデートされる。つまり、スキーマ更新が無くなり、クラス定義における更新処理になり、それは読み出されたオブジェクトだけに行われ軽量で、過去の任意のバージョンから行える。さらに、読み出されたオブジェクトが再び書き込まれる事を通して徐々にDB上のシリアライズされたオブジェクトは最新版のものに更新されていく。
ちなみに、DBの統一処理によって古いデータはシリアライズされたまま最新版にアップデートされるので、その経緯でもDBは最新化される。
オブジェクトをシリアライズして保存し、ほとんどインデックスを作らないから、高機能な検索はできない。しかし、複雑なクエリは人間に凝ったデータを見せるためで内部処理は単純な検索しかないという信念によって、検索機能を外部のプログラムに委譲し、WebAPI等を通じて外部のプログラムにデータを提供し、高機能な検索は外部のプログラムで行う事で、たとえアプリケーションに高機能な検索の需要が生じてもそれは人間が検索機能を使って操作対象のオブジェクトのIDを特定するためであり、内部動作が必要とするわけではないので、解決される。なお、内部動作のためにも僅かにインデックスが構築されるが、ほぼ変更が無いと思われるメンバー変数においてのみインデックスが構築されるだけで内部動作は十分であるという信念によって、インデックスの増加によるスキーマエボリューションの困難は解決される。

その他

なぜP2Pでやるか

まずP2Pの堅牢性について。過半数の参加者が悪質な改ざんをソフトウェアに施す事は考えにくいので、少数派の参加者だけがデータを改ざんしても全体に影響しないような設計にすれば全体としてデータが健全に保たれます。

他にもP2Pは他のシステムに無い特徴を持っています。

国境を超えた承認情報基盤を作れるかもしれない。
オンライン上の自動化されたシステムである。
C/Sと違い管理者による不正に晒されない。
TenyuのP2P技術によって全体運営者を選挙的プロセスで選出できる。
耐障害性が高いオンラインサービスや意思決定システムを構築できる可能性がある。関連：TSAフォルダの初期の文書

ユーザー中心コンピューティングはP2Pを必要とし、本質的に結びつくものです。

ネット上のレビューコメントはいわゆるヤラセやサクラと呼ばれるものがあるがユーザー中心コンピューティングなら解決される。
ネット上のデマもユーザー中心コンピューティングによって解決される。

結局、最も抽象的に述べれば新しい信頼可能な前提を作れるからと言えます。「特権を持つ者（全体運営者など）ですら完全に監視され（透明性）、特権を持つ者を選挙的プロセスで選出できる」この条件が達成されたシステムは他にありません。

なぜ信頼可能な前提を作らなければならないか？ 秩序は信頼可能な前提の上に作られるからです。秩序は例えば事業や人の生活、あるいはオンライン上のSNS構造やユーザー動態等です。一般に秩序は何らかの前提を持っていて、その前提が崩壊すれば一緒に崩壊します。つまり、新しい特性を持つ信頼可能な前提の出現は、新しい種類の秩序の出現を示唆します。P2PはC/Sのシステムと異なり、管理者であっても不正な改ざんができないシステムなので、その点で新しい特性を持ちます。

短所はP2P技術による選挙は、一人一票ではなくコンピューターの性能に応じて票数が変わる事です（ただし従来技術のようにGPUやASIC等でのアクセラレーションは不可能）。あるいはプログラム全般がそうであるようにバグがあるかもしれないというのもあります。

ソフトウェア開発の未来

Tenyuは個人規模のソフトウェアプロジェクトが連携する未来を想定しています。ソフトウェア開発の敷居の低さやコミュニケーションコストの高さや個人制作が可能である性質からそのような形態が適しているからです。もし一人しか開発者が居ないプロジェクトで開発者がやめても、TenyuLicenseでソースコードを公開していたなら他の人がそのソースコードを継承して開発を継続できます。そのような場合でもオリジナルの開発者は相互評価フローネットワークを通じて適切な評価と報酬が得られます。これが従来のFOSSとの違いです。ソフトウェアプロジェクトは高コストな上に成功率が低い。コミュニケーションコストが一因です。ソフトウェア開発の未来は、個人規模のソフトウェアプロジェクトの連携、発明やソフトウェア資産の共有、作者の相互評価による妥当な報酬などが達成され、低コストかつ高成功率かつ多様なソフトウェアプロジェクトが実現されると考えています。

P2P技術と多重送金とオンラインゲーム

良く仮想通貨は多重送金の問題があると言われます。多重送金は他に送金ミス、送金の消失、送金履歴の消失などと言われているようです。仮想通貨はP2P技術によって実現されているので、もしP2Pネットワークでノード間で情報が矛盾した場合、多数派の情報に合わせて少数派が情報を捨ててしまう面があり、少数派グループで送金処理が反映されても多数派グループで反映されていなければ送金処理が消失します。そして自分の送金処理を反映したグループが多数派なのか、それとも実は少数派だったのかはある程度時間が経たないと分かりません。私はそれを多重送金とか送金消失と言っています。（送金消失に統一するのがベターだったか）この問題を応用した攻撃として、残高100しかない送金者が2人の受金者に100ずつで合計200の支払いができるという残高を超えた送金が可能になるという問題があります。この点でその問題は昔多重送金問題と言われていたと思います。

もし仮想通貨の送金に応じて現実のサービスが生じた場合、送金処理が消失する事は重大な問題です。既に提供されたサービスを返品してもらう事はできないからです。物品の返却も面倒です。

多重送金問題は実はオンラインゲームと重要な関りがあります。もしP2Pネットワークがオンラインゲームのアイテムデータを直接管理するなら、アイテム購入メッセージの反映処理は送金とアイテム獲得をまとめてやる事になりますが、もしアイテム購入処理が消失した場合、送金とアイテム獲得が同時に消失するのであり、アイテムだけが残るという事がありません。さらにアイテムの販売側も無限に複製できるデータを提供したに過ぎず致命的な損害は生じません。つまり購入する価値が純粋にオンラインで完結するというオンラインゲームの性質が重要なのです。つまり、P2Pベースのオンラインゲームの決済処理は送金処理が消失する事がほとんど問題にならないという非常に都合のいい性質があります。

他にもオンラインゲームのプレイヤーからすると、ゲーム運営による不正なデータの改ざんがほぼ不可能となり、透明性が高まります。

Tenyuの場合、多重送金という問題はありませんが、代わりに同調処理によって多数派のデータに同調して少数派のデータがかき消される可能性があります。この点でオンラインゲームはTenyuのP2P技術にも適しています。

表記義務がある使用ライブラリ

This product includes GeoLite2 data created by MaxMind, available from http://www.maxmind.com.

https://dev.maxmind.com/geoip/geoip2/geolite2/

The GeoLite2 databases are distributed under the Creative Commons Attribution-ShareAlike 4.0 International License. The attribution requirement may be met by including the following in all advertising and documentation mentioning features of or use of this database:

バージョンアップのセキュリティ

基盤ソフトウェアはソースコードが公開されますが、reproducible buildsである必要があります。現状それを達成する方法は確立していません。今後の課題。

ビルドチェーン攻撃のリスク

このプロジェクトが利用しているライブラリ等にウイルスが混入する可能性について。
このプロジェクトはMaven Central等の世界的に利用されているmavenリポジトリサービスと多数のオープンソースライブラリに依存しています。それは現状のソフトウェア開発において妥当な選択だと思います。有名なサービスやライブラリは世界中のハッカーの標的になる一方で、特に厳しく監視されているとも言えます。ビルドチェーン攻撃のリスクはソフトウェア開発全般の問題であり、私はまだ明確な答えを持っていません。 programmingEnvironment.mdでセーフランチャーというアイデアやreproducible buildsを実現する方法について少し書きました。

競技を通じた報酬

今後AIの発展次第ではほとんどの仕事が奪われます。そうなった時、競技を通じた報酬は希望になります。競技ならどのような道具を使用して良いかルールで制限できます。大抵の仕事は効率だけが追及されますが、そのせいでほとんどの仕事がAIに置き換えられます。 Tenyuの構想で言えば競技を通じた報酬はレーティングゲームにおけるプレイヤー報酬です。

vtuber現象

個人がネット上で一貫したアバターを使用するようになります。いずれアバターを様々なオンラインゲームや、場合によってオフラインゲームでも一貫して使用できるようになるでしょう。アバターを通じて周囲からの認知が生じ、他のアバターとの関係も生じます。オンラインゲームは多様なアバターによって彩られます。その点で従来と異なる表現や人的動態が可能になります。

なぜ仮想的なアイテムが価値を持つか

大勢の人々がゲーム文化を持っていてゲームに時間を使うので、その時間をオンラインゲームの仮想的なアイテムの入手に向けさせると、DUPEやBOTなどの問題が生じていない限りそのようなアイテムの入手には相応の人月を費やす必要があるということになり、時間の節約または他のプレイヤーより有利なキャラスペックを持つためにアイテムをRMで買う人が出てくる。この時点で仮想的なアイテムに価格が生じます。

アイテムの入手に向かう動機は様々ある。装備の見た目、性能、トロフィー的価値（困難な条件を達成したプレイヤーに記念として送られるアイテム等）、希少性（数時間に１個しかドロップしないアイテム等）、交換価値など。

さらに、自己の成長がデジタルデータによって達成されるという価値観も重要だと思います。オンライン上のアバターのレベルや所有アイテム等デジタルデータによる成長が新たな価値観として生じつつあるという事です。

関連：https://www.4gamer.net/games/005/G000546/20081222001/

Q&A

Q.仮想通貨は価値を持つか？
A.オンラインゲームとRMTは仮想的なアイテムや通貨の価値を実証しました。その後ビットコイン系の仮想通貨もそれを実証しました。
Q.新しい価値が生まれるか？
A.相互評価フローネットワークやオンラインゲーム主軸モデルが生み出す人的動態は新しいものです。
Q.C/Sで出来てP2Pで出来ない事は何か？
A.データセンターやスパコンがP2Pネットワーク上の1ノードとして振る舞えます。
P2P承認情報基盤は特定のノードに特別な役割を与えれます。それはC/Sとほぼ同等の機能性を達成しうることを意味します。
とはいえ、P2PとC/Sを領域に応じて使い分けるのであって、今後もC/S技術は重要です。
Q.既存の経済でもソフトウェアやオンラインゲームを実現できていないか？
A.C/Sのオンラインサービスは運営者の都合で終了し、運営者による不正を阻止できません。
さらにプレイヤーや配信者やMAD作成者など周辺コンテンツの作成者に報酬を与えれません。他のゲームとの連携も基本的にありません。素材の共有やクリエイターの相互評価プラットフォームの共有もありません。
さらに、細かい事ですが、MO型のゲームについてログインせずに今部屋があるのかを簡単に確認する方法がありません。いちいちゲームクライアントを起動して確認する必要があります。過疎が進行したゲームをやりたいと思っても部屋が存在する確率が低くクライアントを起動しなくなります。Tenyuは登録された全てのレーティングゲームについてマッチングの待機人数を提供します。
さらに、最も決定的な違いは、従来のオンラインゲームは日本円等の法定通貨の回収モデルを必要としましたがTenyuの構想が持続するのに法定通貨の回収は必要ありません。
さらに、オンラインゲームの運営がゲームバランスを崩すような有料アイテムを追加したり、回収できなくなればサービスが終了しました。多くの場合オンラインゲームの運営はどこかのタイミングでゲームの価値を下げてでも回収に動き出します。従来オンラインゲームの運営はプレイヤーのゲーム内資産を人質にとるような方法で回収を行えました。しかし、本構想は独自の仮想通貨を作成し運営も制作者もプレイヤーも仮想通貨を獲得できて、仮想通貨の価値を高めることで全ての立場が利益を得ます。そして全ゲーム共通のゲーム内通貨を使うので特定のゲームが破綻してもゲーム内資産が大部分維持されます。
Q.PC鍵とモバイル鍵を変更したい場合は？
A.keyフォルダの以下のファイルを別フォルダに移してください。モバイル鍵を変更したい場合。
- MOBILEPrivateKey.txt
- MOBILEPublicKey.txt PC鍵を変更したい場合。
- PCPrivateKey.txt
- PCPublicKey.txt 次にgeneratedファイルを削除し、オフライン公開鍵と秘密鍵をkeyフォルダに設置し、Tenyuを起動するとkeyフォルダにPC鍵とモバイル鍵が新規作成されます。その後、機能一覧のユーザーカテゴリーの鍵変更から手続きしてネットワークに登録してください。

FAQ

Q.仮想通貨の信頼性は？
A.P2P技術が成立しているか、エンジニアリングが成功するか、運営の信頼性、参加者数次第。
Q.このプロジェクトを一言で言うと「CPU証明と分散合意の技術を用いて、MMOを軸にした仮想通貨経済圏をつくる」ということですか？
A.その長さの文で表現するならそれより適切な表現はそう無いと思います。しかし、仮想経済は仮想通貨に価値を与えるためにあり、最終的に相互評価フローネットワークを通じてソフトウェアの汎用的マネタイズ手段を確立することこそが主旨です。
Q.技術に関しては、専門家ではないのでよくわかりませんが、このシステムの脆弱性はどこですか？
A.脆弱性は、専門家が評価して見つからなければ恐らくないだろう、と考えるもので、脆弱性があるかないかを判定する簡単な方法はありません。私はエンジニアリングの問題を除けば基礎技術に脆弱性が無いと思っています。世界的に利用されているシステムも専門家が見て脆弱性が無いから恐らく大丈夫と思われてるだけです。
Q.ゲームデザイナーがこのプロジェクトに参加するとは、具体的にどういうことでしょうか？
A.このプロジェクトは、専用サーバー型のゲーム（常駐空間ゲーム）、ホスト型のゲーム（レーティングゲーム）を扱えて、そのような制作物を登録すると仮想通貨の獲得やクリエイター間の相互評価に繋がります。
Q.近傍とは？
A.P2PネットワークにおいてあなたのPCは他の全PCのアドレスを持っているわけではありません。一部のPCのアドレスしか知りません。その一部のPCが近傍です。PCをノード、アドレス交換された事をエッジとすると、P2Pネットワークは有向グラフになります。近傍は有向グラフの概念です。
Q.全体運営者がゲーム運営者の役割をこなすことはありますか？
A.ありません。全体運営者はユーザーやゲームをBANする権限を持ちますが、ゲームの運営には関わりません。ゲーム運営者が腐敗したら、ゲーム運営者を強制的に他の人に変えて、新たなゲーム運営者によってゲームは健全性を取り戻します。さもなくば全体運営者によってそのゲーム自体がBANされます。
Q.このプロジェクトは、ブロックチェーンに民主主義を導入するってこと？
A.ブロックチェーンではありません。分散合意とプロセッサ証明はブロックチェーンを代替する新しいP2P技術です。民主主義的な側面はあります。
Q.運営者が現実で襲われる等してP2Pネットワークが乗っ取られないか？
A.全体運営者は複数居てそこでも投票があります。全体運営者がおかしくなったらユーザーはその権限を減らせるし、他の全体運営者を選出できます。そもそも住所を秘匿できるはずです。
Q.乗っ取る用のパソコン（ユーザー）を数多く用意した企業が１人勝ちするとかありません？
A.この試みが小規模である間、大組織が興味を持つ理由はありません。この試みが大規模になれば、乗っ取りに必要なコンピューターパワーは莫大になります。さらに、乗っ取れてもユーザーが離れて価値が消失するだけで、価値を奪えるわけではないでしょう。そのような方向性で労力を費やすより正常に参加する方が価値が得られます。さらに信用ソースは演算量以外も存在し、演算量だけで乗っ取る場合全演算量の7割程度を占める必要があるだろうと思います。
Q.運営者がエッジ作成等において、不正とも言い難い微妙なえこひいきをしないか？
A.エッジ作成は一人一人の公正さに頼っている面がありますが、どのような公開された成果に基づいてどの程度のエッジを作成したかが公開されます。何の貢献もしてないのにエッジが作成されたとか、重要な貢献をしたのにエッジが作成されないとか弱いエッジしか作成されなかったということがあれば、それは糾弾されるでしょう。
Q.先行者が得しすぎたりしないか？
A.現実のビジネスでは先行者が後発を完全に抑え込む事があります。しかし本構想はソフトウェアの共有を推進するので、新たに共有されたソフトウェアを使う事で後発のソフトウェアは先発のソフトウェアを上回る可能性が高い。
Q.マルチ商法じゃないの？
A.マルチ商法は「誰かに負債を与えなければならないという負債」を作り、指数関数的に負債が増加する現象です。本構想はそのような事を起こすものではありません。ここでは負債という概念を人や組織に課せられた履行ないし遵守しなければならない強制的条件というような広い意味で捉えています。この構想は誰からも集金しません。だからマルチ商法になることはありえません。

交換リングとの共通点について

交換リングは自由貨幣の一種で、私がそのアイデアの中で印象的だったのは、残高を気にせず支払いができることです。残高0でも支払いができて残高がマイナスになります。大抵の場合下限は設けられているようですが、一度も収入を得ていない人が支出可能です。
「無責任支払い」とでも呼ぶべき概念がそこにあります。

Tenyuの相互評価フローネットワークも無責任支払いがあります。一人一人のユーザーが他の人の受け取り額を決定しますが、支払いの主体は共同主体であり個々の主体ではないからです。共同主体が誰にいくら支払うかを大勢のユーザーが各々の裁量で決定します。それを決定したユーザーは少しも支払いません。しかも共同主体は全体運営者の決定があればいくらでも貨幣総量を増やせます。

無責任支払い

仮想通貨分配では共同主体のみが支払うのでユーザーは少しも支払いません。一方でユーザーは相互評価フローネットワーク上で自分が管理しているノードからエッジを作成する権限を持ちます。つまり自分が支払うわけじゃないのに他の人に報酬を与えれます。これによって貢献関係の記述は人々の善意に任せやすくなります。もし自分の残高から他の人に支払うなら貢献があった事を認識していても作成を渋るかもしれません。

AI対策

BOTやAIによる自動プレイはオンラインゲームを破綻させます。 BOTはカオス性が高いゲームを主軸にすれば防げます。例えばPvPなど。 AIを防ぐにはどうすればいいか？最悪の場合、極端に高性能なAIが開発され、不正者はPC1台で数百試合に同時参戦して全てで人間に勝利するかもしれません。最も強力な対策はプレイヤーもAIを使う事です。人間とAIがタッグを組みPvPに参加します。例えばAIの召喚獣と人間のプレイヤーキャラクターがペアで戦う。各プレイヤーのPCで召喚獣用のAIが実行されます。すると、不正者はまず召喚獣において一般プレイヤーの召喚獣と同等の判断力を持つためにPC1台分のコンピュータパワーを必要とし、 1台で数百試合で同時に勝利する事は出来なくなります。不正者がAIを用いて大量の試合で勝利しようとすると試合数に応じて大量のPCが必要になります。

これは大量の試合がAIに攻略される事を防止するための対策です。 1試合たりともAIに攻略されないようにする対策があります。

プレイヤーの信用度や有料アイテムに応じてゲーム内で有利になるようにします。プレイヤーの信用度はプレイヤー間の相互評価を通じて作成します。有料アイテムに応じて有利にするとは、即ちある程度の額投資しなければキャラクタースペックが上限に達しないという事です。不正者はBANされるリスクを伴って活動するので有料アイテムの購入は困難です。

生産設備とソフトウェア

労働者は企業で働くとき生産設備を利用できているからこそ、あるいは多くの人と同じ場所で働けているからこそ高度な価値生産ができている面があります。多くの場合企業で働く意義があるということです。

ところがソフトウェア開発においては、一通りの開発ツールが無料でオンラインで手に入る事や、成果物（ライブラリ等）の自動的な（ネット上に置いておく）共有によって、価値生産が個人的になりえます。

この事実はソフトウェア開発において企業という枠組みが適さない可能性があること、別の形態が可能である事を示唆します。

P2Pプラットフォームとステマ

ネットや雑誌等では色々なランキングが話題になり、あのランキングで１位を取った作品というような理由で注目を集めたりします。しかし、ほとんどのランキングは捏造可能で、実際に捏造が噂されたり内部告発された有名なランキングもあります。ランキングだけでなく口コミも捏造可能です。

C/Sのシステムは常にサーバの管理者による捏造が可能です。

しかしユーザー中心コンピューティングのためのP2Pプラットフォームが確立した場合、捏造不可能なランキングや口コミが可能になります。誰がどんな情報を作ったかが分かるからです。さらにソフトウェアのソースコードが公開され、プログラムとデータ（作成者や更新履歴）は誰もが検証可能です。

クリエイターにとって実際どんな感じ

本構想が実現したとして、特筆すべき事は、TenyuLicenseで素材を公開すると勝手に使用されて勝手にエッジを得ていつの間にか収益化される事です。無料で素材を公開しても収益化されます。

支援者

kyorohiro

Name		Name	Last commit message	Last commit date
Latest commit History 541 Commits
.settings		.settings
DistributedVoteSample		DistributedVoteSample
lib		lib
readmeImg		readmeImg
src		src
tsa		tsa
.classpath		.classpath
.gitattributes		.gitattributes
.project		.project
README.md		README.md
build.xml		build.xml
logo.png		logo.png
pom.xml		pom.xml
programmingEnvironment.md		programmingEnvironment.md
rpc.md		rpc.md
tenyu.policy		tenyu.policy
tenyutalk.md		tenyutalk.md

lifeinwild/tenyu

Folders and files

Latest commit

History

Repository files navigation

License

概要

回収ではなく与えるプロジェクト

簡易な説明

関連した文書

目次

一般用語

ソフトウェア用語

P2P

プラットフォーム

アプリケーション

FOSS

MMO用語

問題

ソフトウェア及び知識生産の収益化構想とMMOとP2Pと社会の関係

ソフトウェアや知識生産の問題

パクり問題

生産性阻害問題

ソフトウェア収益化問題

ソフトウェア改修問題

ソフトウェア特許問題

プログラマーの不足問題

C/Sの問題

MMOの問題

コンテンツ消費問題

エンドコンテンツ問題

P2P技術の問題

演算量証明受付時間問題

ハードウェアアクセラレーション問題

更新性能問題

ノード信用問題

プロジェクトの経緯や状況や一般的側面

Tenyu基盤ソフトウェア

プロジェクトの状況

ソフトウェアの状況

免責事項

プライバシーや動作等に関するポリシー

採用したソフトウェアの構成

基盤ソフトウェアのソースコードの公開

Tenyu基盤ソフトウェアを実行するリスク

私

プロジェクトの経緯

想定される参加者

Tenyuプロジェクトに影響を与えた創作的成果

必要スペック

推奨スペック

Tenyuの実行環境

Javaでゲームを作る

TenyuのP2P技術の概要

Tenyuの性能

仮想通貨の流れ

仮想通貨分配

プレイヤー報酬

選挙的プロセスで決定できる情報

紹介制ユーザー登録

アンケート機能

社会

創作活動を守る権利

作者権

著作者人格権は財産権か

なぜ社会を騙してはいけないか

プロジェクト権

人権

TenyuLicenseの概要

TenyuLicense

独自用語ないし解釈

FOSSとは

MMOとは

創作とは

創作活動の動機

ソフトウェアの経済的性質

承認情報

承認情報基盤

P2P承認情報基盤

資本