2025年9月7日日曜日

p5 × GLSL-mini DSL (Logical Grid × Dot Size)

p5 × GLSL-mini DSL (Logical Grid × Dot Size)
投稿者

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説（約600字

最小PBR（GGX・直射）— 冒頭解説（約600字）

最小PBR（GGX・直射）— 冒頭解説

このシェーダは、球1個をレイトレし、GGXベースの最小PBRで直射1灯の見え方を計算します。まずカメラからのレイと球の交差を求め、ヒット点の法線 N、視線 V、光線 L を作ります。鏡面はマイクロファセットBRDFで、法線分布は GGX、幾何項 G は Smith の Schlick‑GGX 近似（$k=((r+1)^2)/8$）、フレネル F は Schlick 近似を用います。

$$ F(\theta)=F_0 + (1-F_0)(1-\cos\theta)^5 $$

粗さ $r$ から $\alpha=r^2$ とし、NDF は次式です。

$$ D=\frac{\alpha^2}{\pi\,\big((\mathbf{N}\!\cdot\!\mathbf{H})^2(\alpha^2-1)+1\big)^2} $$

エネルギー保存のため拡散は

$$ k_d=(1-F)(1-\text{metallic}),\qquad f_{\mathrm{diff}}=k_d\,\frac{\text{albedo}}{\pi} $$

とし、金属（metallic=1）では拡散が消えます。最終輝度は

$$ L_o=(f_{\mathrm{diff}}+f_{\mathrm{spec}})\,(\mathbf{N}\!\cdot\!\mathbf{L})\,L_i $$

を一灯ぶん評価し、わずかな環境色を加えてガンマ補正（$1/2.2$）で表示します。パラメータは Blender の Principled と整合し、Base Color→albedo、Metallic、Roughness が同義です。短いコードと基本式だけで「金属らしさ」や「粗さによるハイライトの広がり」を再現でき、さらに IBL、影、ACES トーンマップを加えると実写感が一段と高まります。

https://www.shadertoy.com/view/3cScDD
投稿者

Web3広告ネットワーク

 

すでに動いている/資金調達している主な類型と企業

  • Web3広告ネットワーク（ウォレット/ dApp面の配信）
    HypeLab：ウォレットやdApp・NFTマーケットプレイス内に配信、オンチェーン/オフチェーン属性でターゲティング。23年に**$4M**調達。 hypelab.com+1The Block

  • オンチェーン計測・アトリビューション
    Spindl：Web2⇄Web3横断の計測（AppsFlyer連携）/ 22年に**$7M**調達。 Axiosblog.spindl.xyz

  • Web3オーディエンス構築（アドレス⇄Web2紐付け/拡張）
    Addressable：23年に**$7.5M**→24年に累計$13.5M。ウォレットに基づくマーケ堆積を提供。 addressable.io+2addressable.io+2

  • 分散型アドエクスチェンジ/プロトコル
    Ambire AdEx：17年からの広告プロトコル（支払いチャネル/スマコン決済）。初期に約**$10–12M**規模の資金調達（ICO）。 GitHubadex.network+1

  • ユーザー報酬型ブラウザ広告
    Brave / BAT：ユーザーが同意して広告を受け取り、BATで報酬。Roadmap 3.0ではオンチェーン連携やクエスト強化。 Brave+1

  • “クエスト/タスク”型の獲得（オンチェーントライアル=成果）
    Galxe、Layer3、Zealy：大規模ユーザー基盤・23–24年に資金調達（Layer3は**$15M Series A**）。広告の代替として成果タスクを組むユースケースが一般化。 galxe.comLayer3PYMNTS.com

  • アドフラウド対策（オンチェーン検証）
    Verasity（Proof-of-Viewでビュー検証、VeraViews提供）。 OKXverasity.io

Web2アドテクと比べた利点（＋理由）

  • 成果の“可監査性”が高い：ミント/スワップ/入金などオンチェーンの最終イベントをコンバージョンにでき、スマコンに記録→レポートの食い違いを縮小。ZKや分散台帳での監査性も研究・実装が進展。 arXiv

  • 同意ベースのID（ウォレット）：**SIWE（ERC-4361）**で署名ログイン→クッキー不要でもセッションと同意管理が可能。スマコンウォレットの署名検証（EIP-1271）にも対応。 Login.xyz+1ethereum.org

  • 自動レベニューシェア/即時決済：支払いをスマートコントラクトで自動化（エスクロー/ストリーミング/上限管理など）。AdEx系は支払いチャネルでマイクロペイメントを大量処理する設計。 GitHub

  • “ウォレット内”のリーチ：従来のウェブ面では届きにくい**実利用者（保有資産・トランザクション有り）**に直接配信可能。 hypelab.com

  • ユーザーと利害が一致する設計：Braveのようにユーザーへ還元するモデルが標準機能として存在。 Brave

  • フラウド耐性の強化余地：ビュー/クリックの“申告値”より、検証可能なイベント（オンチェーン）を課金根拠にできる。PoVのようなビュー真正性検証も登場。 OKX

ただし（現実的な留意点）

  • 到達規模/在庫の成熟度：Web2の巨大在庫・ブランドセーフティ標準（IAS/DoubleVerify等）に比べ、Web3は在庫/測定の標準化が発展途上。Quest型で補完する動きが主流。 Layer3

  • ID断片化とSybil対策：チェーン/ウォレット跨ぎの重複、スマコンウォレット署名（EIP-1271）対応の実装差など、運用ノウハウが必要。 ethereum.org

  • Web2側の環境は“まだ動的”：Chromeの3rdパーティCookieは段階的制限の計画が度々変更/遅延。Privacy Sandbox（Attribution Reporting API等）は動き続けており、Web2計測も並行で必要。 Privacy Sandbox+1Wall Street Journal

  • 日本の広告・景品規制/暗号資産規制：表示義務・誇大表現の禁止（景表法/JVCEA指針）に注意。対価や特典（NFT/トークン付与）は景品類上限やリスク表示等の要件を満たす設計が必要。 CAA Japan一般社団法人 日本暗号資産取引業協会（JVCEA）t2fifa.or.jp

どう活かすか（実務Tips）

  • 配信：まずはHypeLab等のウォレット面在庫でCPA/CPE試験運用。 hypelab.com

  • 計測：SIWE署名＋campaignIdでクリック識別→オンチェーン成果と1:1照合。Web2計測（AppsFlyer等）とSpindl連携で“Web2→オンチェーン”のラストタッチを補完。 blog.spindl.xyz

  • 不正対策：成果はオンチェーンイベント＋PoV/独自検証の二重化、SC側でcooldown/上限/nonce。 OKX

投稿者

もともとインターネット自体ディスクロージャーだったはずですけど、マネタイズその他、そうはならなかったですね

 もともとネットは「仕様・由来を公開して接続する」文化（RFC/W3C/ブログ）でしたが、収益化とモバイル化で“逆ディスクロージャー”が進みました。要点だけ整理します。

3段階の変遷

  1. 開示指向（〜2000）
    　公開規格・実名的コミュニティ・リンクで評価＝可視。

  2. 不可視化の進行（2000–2010s）
    　アドテク/入札/指紋採取、推薦アルゴリズム、アプリ化で“箱化”。

  3. 規制主導の再ディスクロージャー（2020s–）
    　広告ライブラリ、ステマ規制、C2PA/AIラベリング等で部分的に回帰。

逆転を招いた力学（5つ）

  • 競争優位：データと最適化手法は隠すほど儲かる

  • プライバシー規制の副作用：同意UIは増えたが実態は見えにくい

  • プレミアの壁：有料層で情報非対称が拡大

  • 濫用対策：スパム/荒らし対策名目で基準がブラックボックス化

  • インフラ回収：ログや計測が企業内に囲い込まれた

いま実務でできる「設計の原則」

  • 目的別開示：①推薦理由 ②広告/アフィ関係 ③生成物ラベル（AI/C2PA）

  • 二重ログ：内部監査ログ＋ユーザー向け“ミニ開示ログ”（誰に何が届いたかの要約）

  • 透明性API：出稿・配信・推薦の要約エンドポイントを外部公開

  • プレミア再設計：有料でも開示文言は無料で誰でも閲覧可

  • 合意UI最適化：1画面1目的・履歴参照・いつでも撤回

進め方（軽量KPI）

  • 可読開示率（開示文を実際に読まれた割合）

  • 関係性明示率（提携/ギフティング表示の網羅度）

  • 推薦理由開示率（リコメンドの“なぜ”を提示した配信の割合）

投稿者

ブロックチェーンがプライバシーについて二極化をもたらすと仮定できますか？

 ざっくり言うと「開示ど真ん中のKYCゾーン」と「選択的秘匿ゾーン」の二極化です。

  • 規制ドリブンに“丸見え化”
    FATFのトラベルルールやEUの新AML規則で、送受信者情報の伝達・匿名口座の禁止などが強化。結果、取引所や“規制対応型L1/L2”は高開示へ収束します。FATFコンシリウムノートン・ローズ・フルブライト

  • 産業側の「公開」圧力
    MiCAは発行体にホワイトペーパーの詳細開示を義務づけ、広告表現の制約も。コンプラ重視のRWAやステーブル群は“見せる”設計に寄ります。EUR-Lex+1

  • 逆方向の“秘匿”技術も進化
    Zcashのzk-SNARK、Aztecなどのプライバシー志向ZKロールアップ、FHE系L2（Fhenix等）が計算や状態そのものを暗号化して選択的開示を可能に。Zcash DocumentationZ.CashAztec DocumentationCoinDeskChainwire

  • 「選択的ディスクロージャー（zkKYC）」の台頭
    Polygon ID等のVC/zk証明で、必要最小限だけ証明（例：年齢/KYC済み）する実装が増加。全面開示と完全秘匿の中間が厚くなります。PolygonCryptoSlate

  • 監視の“性能向上”が分極を補強
    研究・実務のアドレス／トランザクション・クラスタリングで疑似匿名は可視化されやすい。可視ゾーンはより透明に、秘匿ゾーンはより強い暗号へ。コンピュータサイエンスUSENIX

  • エンフォースメントの揺れ
    Tornado Cash制裁（2022）→訴訟・取扱い指針・最近の動きまで、プライバシー手段と法執行の綱引きが続いています。U.S. Department of the Treasury+1Axios

帰結（実務の前提）

  1. CEX/規制対応L2/許可型チェーン＝高開示・追跡前提

  2. ZK/FHE系L2・プライバシー通貨＝選択的秘匿前提

  3. 中間層＝zkKYC＋ログ最小化の設計（監査には耐え、個人情報は出さない）

いまの設計指針（簡潔）

  • “開示と秘匿の分離”を要件化：公開メタデータと秘匿データの境界を明文化

  • zkKYC/VCで二値KYCを脱し、「条件を満たす」のみ証明

  • 監査用ログは保持、公開ログは最小限・選択的

  • 地域展開はMiCA/AML/トラベルルール差分表で運用

投稿者

秘匿方向のweb3のweb2と比較した利点を教えてください

 

  • 最小開示（Selective Disclosure）
    zk/VCで「18歳以上」等だけ証明。Web2は本人情報そのものを提出・保管しがち。

  • 計算の秘匿
    MPC/FHE/TEE等で“中身を見ずに計算”。Web2は担当者や運営が内容を閲覧し得る。

  • 検証可能で非公開
    第三者は“正しさの証明”だけ検証でき、基データは非公開のまま。Web2は監査で原本提出が前提。

  • プラットフォーム横断の再利用
    一度の証明（VC/zk）を別サービスでも使い回せる。Web2はサービスごとに再登録・再提出。

  • 公開台帳との“選択的接続”
    ステルスアドレス/シールドプール等で取引のリンク性を制御。Web2は中央DBで統合・突合されやすい。

  • コンプライアンスの“コード化”
    「証明が無ければスマコン実行不可」など、運用ではなく実装で強制。Web2はポリシー・監査依存。

  • 監査の低侵襲化
    View key/監査用鍵で“必要範囲のみ”開示。Web2は全件エクスポートや現地監査が必要になりがち。

  • 漏洩リスクの縮小
    そもそも個人データを“保持しない”設計が可能。Web2は保有前提で漏洩面積が大きい。

  • 耐検閲・停止点の分散
    分散台帳＋リレー/ロールアップで単一停止点を回避。Web2は事業者・国境で遮断されやすい。

  • メタデータ分離
    コミットメント/ノート設計で金額・相手・頻度などの露出を抑制。Web2は決済・広告事業者に集約。

代表ユースケース

  • 年齢/居住地などの属性証明（本人情報は非開示）

  • プライベート投票・評議（正当性は公開、投票内容は秘匿）

  • 企業間の機微データ連携（合算/検証のみ共有、原データは秘匿）

  • 地域/資格限定のエアドロップ（条件充足のみ証明）

注意：L1の透明性、オンランプ/KYCでの再識別、解析による追跡リスクは残ります。**“何を公開し、何を証明だけにとどめるか”**の設計が肝要です。

投稿者

確率質量関数（PMF）と期待値の関係｜サイコロとコイントスで直感的に理解

確率質量関数（PMF）と期待値の関係｜サイコロとコイントスで直感的に理解

確率質量関数（PMF）と期待値の関係｜サイコロとコイントスで直感的に理解

確率質量関数（PMF）は離散確率変数が各値をとる確率を与える関数です。本稿ではPMFを使って期待値をどのように計算するかを、サイコロとコイントスの例で整理し、ベルヌーイ／二項分布やエントロピーとの関係まで簡潔に補足します。

保管版HTML（元記事：note） / 最終更新: 2025-09-06

補足①：定義の再確認（PMFと期待値）

離散確率変数 \(X\) のPMFを \(p(x)=P(X=x)\) とすると、期待値は

\[ E[X]=\sum_{x} x\,p(x) \]

となります。サイコロでは \(p(1)=\cdots=p(6)=1/6\) なので

\[ E[X]=\frac{1+2+3+4+5+6}{6}=3.5 \]

—「平均的に得られる値」を表します（実際に出る値とは限りません）。

補足②：ベルヌーイ分布の期待値と分散（式の最短導出）

コイントスのように \(X\in\{0,1\}\)、成功確率 \(p\) のとき

\[ E[X]=p, \quad \mathrm{Var}(X)=p(1-p) \]

はPMFから1行で導けます（\(E[X]=0\cdot(1-p)+1\cdot p\)）。検索意図に合う公式明示で到達性を高めます。

補足③：二項分布への一般化（頻出QA対策）

独立なベルヌーイ試行を \(n\) 回：

\[ E[X]=np, \quad \mathrm{Var}(X)=np(1-p) \]

「コイントスを何回も」は実用的な問い合わせが多く、最短で応答できるよう公式を記載しておきます。

補足④：PMF・PDF・CDFの違い（1分要約）

  • PMF：離散。棒グラフの高さ=確率。
  • PDF：連続。曲線の面積=確率（高さそのものは確率ではない）。
  • CDF：閾値以下である確率の累積。

検索で混同されやすい用語の「即答」を本文内に用意しておくと流入の取りこぼしを減らせます。

補足⑤：エントロピーとの関係（2値のとき）

二値の不確実性は

\[ H(p)=-p\log_2 p-(1-p)\log_2(1-p) \]

で最大は \(p=0.5\)。本文の話題（シャノン）を式で補強して内部一貫性を高めます。

補足⑥：Python最小コード（張り替え可）

# PMFから期待値を出す最小例（サイコロ）
xs  = [1,2,3,4,5,6]
pmf = [1/6]*6
E = sum(x*p for x,p in zip(xs, pmf))
print("期待値:", E)  # 3.5

# ベルヌーイと二項（導出確認）
p, n = 0.3, 10
E_ber, Var_ber = p, p*(1-p)
E_bin, Var_bin = n*p, n*p*(1-p)
print(E_ber, Var_ber, E_bin, Var_bin)

補足⑦：よくある質問（FAQ）

Q. 期待値は実際に出る値ですか？
A. 平均的傾向を表す量で、必ず観測される値ではありません（サイコロの3.5など）。
Q. 偏りコインの期待値は？
A. 成功確率 \(p\) です（成功=1, 失敗=0 と定義した場合）。
Q. PMFとPDFの違いは？
A. 離散か連続かで解釈が異なります。PMFは高さが確率、PDFは面積が確率です。

メタ情報とタグ

ディスクリプション：確率質量関数（PMF）から期待値をどう計算するかを、サイコロとコイントスで直感的に解説。ベルヌーイ／二項、PMF・PDF・CDFの違い、エントロピーも簡潔に補足。

推奨タグ：#確率 #統計 #期待値 #確率質量関数 #ベルヌーイ #二項分布 #エントロピー

© 2025 Minoru Oka（保管用HTML）。本ページは元記事の構成を尊重し、最小限の補足を加えています。

投稿者
登録: 投稿 (Atom)