BLUEPRINT

第4章：MeriTokenモデル

4.1 モデル概要

MeriTokenはGMCの核心的測定単位です。その設計は一つの重要な問いに答えなければなりません：貢献測定はどのようにして現在の活動を反映しつつ、歴史的貢献も尊重できるのか？

答えは：指数減衰 + 非ゼロのフロア値です。

4.2 2つの重要な値

各MeritPocketは2つのコア値を維持します：

  • curMerit（現在のMeriToken）：リアルタイムの貢献測定値。時間とともに減衰し、新たな貢献で増加します
  • minMerit（フロア値）：減衰の下限であり、歴史的貢献の長期的な沈殿を表します。増加のみ（罰則を除く）
curMerit ≥ minMerit ≥ e（初期値）

4.3 取得

MeriTokenは貢献を通じて取得され、システムが新しいTokenを鋳造します：

取得方法説明トリガー条件
客観的測定検証可能な指標に基づき自動計算システムが閾値到達を自動記録
タスク報奨特定タスクに対するMeritのプリセット完了時にステークホルダーが投票で承認
初期配分ネットワーク登録時に付与アイデンティティ登録完了

初期値 = e ≈ 2.718（自然定数、指数減衰モデルと自然に整合します）。

4.4 減衰モデル

核心的アイデア

各Merit取得バッチは独立した影響期間を持ちます。影響期間はその貢献の時間的有効性を反映します — 100日の影響を持つ貢献は、100日以内にそのMeritが完全に減衰します。

単一バッチの減衰公式

MeriToken_i(t) = (V_i - B_i) × e^(-λ_i × t) + B_i
  • V_i：バッチの初期Merit値
  • B_i：バッチのフロア値への寄与分
  • λ_i：減衰係数、影響期間T_iによって決定（λ_i = k / T_i、kは定数）
  • t：取得からの経過時間

合計現在MeriToken

curMerit = Σ MeriToken_i(t)  （すべてのアクティブバッチの合計）

すべてのバッチが完全に減衰すると、curMeritはminMeritに近づきます。

4.5 フロア値（minMerit）

更新ルール

新しいMeritが取得されるたびに、フロア値が更新されます：

現在のcurMerit = M、新規取得Merit = x、現在のフロア値 = Bとすると：

新しいフロア値 B' = (x + M) × B / M

意味：フロア値は新しいMeritの合計に対するシェアに比例して成長します。

性質

  • 開始値 = e ≈ 2.718
  • 増加のみ（罰則を除く）
  • 歴史的貢献の消えない沈殿を表します
  • 貢献が完全に停止しても、curMeritは最終的にminMeritを下回ることはありません

エッジケース

curMerit = minMerit（つまりフロア状態）のときに新しいMerit xが取得された場合：

B' = (x + B) × B / B = x + B

フロア値はxだけ直接増加します — つまりフロア状態で取得されたMeritは全額がフロア値として沈殿します。

4.6 バッチ別独立減衰の実装

課題

  • 各MeritPocketはMeritバッチのリストを維持する必要があります
  • 現在値のクエリには完全に減衰していないすべてのバッチの反復が必要です
  • オンチェーンのストレージと計算コストはバッチ数に比例して線形に増加します

最適化戦略

  1. バッチ統合：類似の影響期間を持つバッチを定期的に統合し、アクティブバッチ数を削減します
  2. オフチェーン計算：Rollupを使用してリアルタイム値をオフチェーンで計算し、スナップショットと証明のみをオンチェーンに保存します
  3. バッチ沈殿：最大アクティブバッチ数を超えた場合、最も古いバッチが自動的にフロア値に沈殿します
  4. 遅延計算：必要な場合（投票やクエリ時など）にのみ正確な値を計算します

4.7 設計哲学

なぜ指数減衰なのか？

  • 一度の大きな貢献の後に活動を停止するのではなく、継続的な貢献にインセンティブを与えます
  • 貢献の時間的有効性を反映します — より最近の貢献が現在の評判により大きな影響を与えます
  • 社会的記憶の減衰を自然にシミュレートします
  • 最初は急速に減衰し後に緩やかになり、直感に合致します

なぜ非ゼロのフロア値なのか？

  • 歴史的貢献の長期的価値を認めます — 過去の努力が完全にゼロにはなりません
  • 長期的な貢献者が短い休止によってすべての発言権を失うことを防ぎます
  • フロア値は累積的な貢献とともに成長し、持続的な参加に報います

なぜバッチごとに独立した影響期間なのか？

  • 異なる貢献は自然に異なる時間的有効性を持ちます
  • 一回のカスタマーサービス対応は30日程度の影響しかないかもしれません
  • オープンソースプロジェクトの維持は数年にわたる影響を持つかもしれません
  • 一律の減衰率は異なるタイプの貢献の価値を歪めてしまいます

4.8 議論メモ

MeriTokenモデルにおける重要な決定：

  • 指数減衰 + 非ゼロのフロア値：「継続的参加のインセンティブ」と「歴史的貢献の尊重」のバランスを取ります
  • バッチごとの独立した影響期間：実装の複雑さは増しますが、貢献の時間的有効性の違いをより正確に反映します
  • フロア値は増加のみ（罰則を除く）：長期的な貢献者の基本的権利を保護します
  • 初期値e：数学的な美しさと実用的な意義を兼ね備えています

さらなる検討事項：フロア値の更新公式が極端な条件下で合理的に振る舞うかどうか