くいしんぼう日記

選択可能性、共創について考える日々

Zero Knowledge SSO

この記事について Decentralized SSOはすっごく前に作った作品ですが、それにZK（Zero Knowledge Proof）を追加したプロトコルを作りました。この記事では、そのプロコトル制作の背景やプロコトルについて書きます。正直、プロトコルと言うほど崇高なものではないですが、便宜上そう言ってます。 Zero Knowledge SSOに行き着くまで前まではZKの意義深さがよく分からずにスルーしていたのですが、今年（2024年）の7月にZKの重要性を理解しました。これは回路を書いたりと手を動かしてみたことが大きいと思います。 ZKの数学は難しいのですが、有用なライブラリ多いため実際に手を動かす分には数学無しでも扱えるようになっています。そこからアプリケーションでもっとZKが使われて欲しい！との思いから、数学なしでZKのアプリケーションを作るための記事を書いたりしていました。さて、それが一段落したところで、ZKを使ってSSOできないかな、と思い立ちました。というのも、以前に作っていたDecentralized SSOでの課題を解決できそうな気がしたためです。 Decentralized SSOでは複数のIdPからユーザの信頼情報を取得しますが、その際に複数のサービス間で同一のアイデンティティを利用するためアイデンティティが紐づくというプライバシー上の懸念がありました。そこでZKを使うことで、ユーザの信頼情報のみを取得し、アイデンティティを紐付けないでSSOを実現できるのではないか、と考えました。色々と調べていくうちに、Ethereum財団のPSE（Privacy and Scaling Explorations）がSemaphoreというアイデンティティ関連のライブラリを作っていたため、それを利用することにしました。また、PSEがAcceleration Programというタスクにお金を払うプログラムをやっていたため、それに応募できそうだと思いました。ということで、１週間程度で雑にプロトタイプと仕様を作り、それを提出しました。 PSEの人がレビューをした後、今ちょうどスマホの鍵管理アプリを作っているプロジェクトがあって、それと統合したらどうだろうか？と言われました。スマホアプリで実際に実現が出来そうだったので、それに同意してそのプロジェクトが完了するのを待っている最中です（2024/10/07 現在）。待ち続けて2ヶ月以上経つので、一旦アウトプットとして書いておきます。なお、以下はEthResearchにも投稿した内容の日本語版です。プロトコル概要 Anoidenは、ゼロ知識証明を用いた匿名シングルサインオンプロトコルです。このプロトコルは、アイデンティティプロバイダー（IdP）とサービスプロバイダー（SP）が共謀しても、ユーザのアイデンティティを秘密に保ちながらIdPからの情報を使ってSPへのサインインを可能にします。これはSemaphoreライブラリを利用します。 Connect ユーザは、IdPが指定する方法（Eメールや電話番号の登録など）でアカウントを作成し、ゼロ知識証明の鍵と接続します。 Auth SPはIdPを信頼しており、認証のエンドポイントを知っています。ユーザはSPに対してIdPでのログインを要求し、ノンスを取得します。その後、ユーザは自身のアイデンティティの証明を作成しIdPに送信します。IdPは証明を確認し、ユーザが正当であれば対応する署名を作成します。用語拡張機能: ブラウザ拡張機能（アプリでも可）で、ユーザの鍵管理や証明の作成等を行います。SPとIdPが結託してもアイデンティティが秘匿されるために必要です。 anoiden.js: ウェブサイトのクライアントに拡張機能と通信するためのインターフェイスを提供します。アイデンティティプロバイダー（IdP）: ユーザの正当性の情報をSPに提供する主体です。サービスプロバイダー（SP）: IdPから提供されるユーザの正当性を利用する主体です。 IdPへの登録（Connect）ユーザがIdPでアカウント登録を完了すると、そのアカウントと拡張機能側の鍵を連携できます。この連携により、ユーザは今後、認証を要求された際にこのIdPを使用可能になります。また、鍵を使って匿名でIdPにログインすることも可能になります。 IdPのクライアントはanoiden.jsを通じて、署名と公開鍵を取得します。 const {signature, publicKey} = await connect(serviceName, nonce); ここでserviceNameはIdPのサービス名で、鍵の管理に使用されます。 nonceは推測が不可能な文字列で、IdPのサーバサイドから取得します。以下の図はIdPのクライアントがユーザの署名を取得するまでのフローです。クライアントは取得した署名、公開鍵、ノンスをサーバに送信します。サーバはセッションを確認し、そのユーザに対してそのノンスを発行したかを確認します。有効であれば署名を検証し、identifier（公開鍵のposeidonハッシュ）を取得し、Merkle Treeにidentifierを追加し、追加後のMerkle Rootを保存します。 Authorize SPはIdPを利用する際、事前に利用することを伝えており、IdPからクライアントIDを受け取っていることとします。...

Portable Web

本記事について以下はEthResearchに投稿したものの日本語訳です（機械翻訳を使ったため、誤訳が含まれる可能性があります）。既存のウェブでは、ユーザは自分のデータを管理することが難しく、サービスにロックインされています。「ポータブルウェブ」は既存のウェブと並行して存在し、ユーザーにデータに対するより大きなコントロールを提供し選択の幅を広げることを目指しています。ポータブルウェブ上のアプリケーションは、主に公共インフラとしての役割を果たすものを想定しています。本記事では、ポータブルウェブの核心的なアイデアを紹介します。その実現可能性に直接関係のない詳細な仕様は含まれていません。要約ハッカブル：ユーザーがウェブアプリケーションをカスタマイズできるクラスターは単一のアプリケーション単位を表します。誰でもクラスターを作成でき、クラスター内では、クラスター作成者以外の主体が自分のクライアントを作成したり、サーバーを提供したり、APIスキーマを定義したり、マイグレーションスクリプトを書けます。クライアントとサーバーは疎結合で、APIスキーマを通じて接続され、異なる開発者が独立して作成できます。例えば、ユーザーは自分のニーズに合わせたカスタムUIを作成し、アプリケーションを使いやすくすることができます。また、自分でAPIスキーマを開発し、特定の機能を拡張するためのサーバーをホスティングすることも可能です。このように、ポータブルウェブでは、開発者だけでなく一般ユーザーもアプリケーションの進化に積極的に貢献できます。データロックインなし：ユーザーが自分のデータをコントロールできるクライアントはユーザーのデータをキャッシュします。 APIスキーマに準拠したサーバーを使用することで、クライアントは異なるサーバー間でキャッシュされたデータを共有できます。クライアント上のキャッシュデータは、マイグレーションスクリプトを使用して移行することも可能です。クライアントはユーザーが送受信するデータをキャッシュしますが、このデータをユーザーが選択したサーバーに送信することで、分散的に管理されます。必要に応じて、ユーザーは自分のデータを他のサーバーに移行でき、特定の組織にデータがロックインされることを防ぎます。クリプトネイティブ：インセンティブメカニズムとしてのクリプトエコノミクスポータブルウェブでは、クラスター提供者がトークンを発行し、そのトークンへの実需を生むクラスターを提供することでインセンティブを得ます。クラスター内のすべての支払いは、発行されたトークンで行われます。新しい参加者の存在はクラスターの成長に貢献するため、元のクラスター提供者は彼らを排除しません。 Web2が独占や勝者総取りのゲームとして機能する一方で、ポータブルウェブは協調的で包摂的なアプローチを促進します。背景 Web2 Web3コミュニティでは、Web2の問題点について広く議論されていますので、ここでは深く掘り下げません。しかし、強調しておきたいのは、Web2の問題の根本はそのアーキテクチャにあるということです。具体的には、ブラウザがターゲットのURLに直接アクセスする方式です。 Web2のアーキテクチャでは、ユーザーは自分が生成したコンテンツを所有権やローカルコピーを保持せずにサービスに直接投稿します。ユーザーのアカウントやコンテンツはサービス内に存在し、そのサービスがデータを蓄積します。この蓄積は新しいデータの生成を加速させます。ユーザーが別のサービスに移行して同じレベルの利便性を得ることは非常に困難です。そのためには、ユーザー自身がコンテンツを移行する必要があり、他のユーザーも大規模に移行する必要があります。既存のウェブアーキテクチャは、コンテンツのロックインやアカウントのロックインを引き起こし、それが権力の集中や勝者総取りのダイナミクスを助長します。 Web3 Web3は既存の権力構造に挑戦し、ユーザーの権利を最大化するとしばしば主張されますが、実際には現在のところ、Web2の上にブロックチェーン層を追加しているに過ぎません。ブロックチェーンは分散型ですが、既存のWeb3アプリケーションが現在のウェブアーキテクチャの上に構築されているという事実は、そのポテンシャルを損なっています。ポータブルウェブのアーキテクチャ上記の問題を解決し、ユーザーの権利を最大化しながら分散型のウェブを実現するためには、新しいアーキテクチャを構築する必要があります。その提案された解決策がポータブルウェブです。この新しいウェブアーキテクチャは、ユーザーが自分のデータとアイデンティティを完全にコントロールでき、開発者やサービス提供者が協力して単一のアプリケーションを進化させることを可能にします。ポータブルウェブの構成要素ポータブルウェブブラウザブラウザは、ポータブルウェブを実現するためにいくつかの重要な役割を果たします。制御されたサーバー通信：クライアントが通信できるサーバーを制限します。ユーザーが明示的に意図しない限り、クライアントはサーバーとやり取りできません。通貨の制限：アプリケーション内での支払いに使用される通貨を制限します。ブラウザにはウォレットが含まれており、支払いはクラスターで最初に設定された通貨でのみ行われます。デフォルトでは、ブラウザは内部の取引所（DEXまたはCEX）と連携しているため、ユーザーは使用されている通貨を意識しません。アイデンティティ管理：ユーザーのアイデンティティを自己主権型アイデンティティ（SSI）として管理し、サーバーやクライアントがユーザーのアイデンティティをロックインすることを防ぎます。ブートストラップのためのビルトインサポート：インデックスクラスター用のクライアントとサーバーの情報が内蔵されており、ブートストラップをサポートします。ユーザーは後で他のクライアントやサーバーに接続できます。データ移行と更新：クライアントで指定されたマイグレーションスクリプトを実行してデータを転送し、クライアントの更新を管理します。クラスタークラスターは、その目的ドキュメントによって識別される単一のアプリケーションを表します。クラスターを構成する要素は次のとおりです：目的ドキュメント APIスキーママイグレーションスクリプトクライアントサーバー誰でも目的ドキュメント以外のコンポーネントを提供して、クラスターの開発と進化に貢献できます。インデックスクラスターインデックスクラスターは、ポータブルウェブ内のApp Storeのような機能を果たします（誰でも提供可能です）。クラスターのコンポーネントの提供者は、自分のデータをインデックスクラスターに登録します。インデックスクラスターはこの登録されたデータをホスティングし、ユーザーに情報やソフトウェアを提供します。また、その情報にはバージョンや互換性などの情報も含まれます。インデックスクラスターは、どのコンポーネントがどのクラスターに属しているかを知っており、サーバーとAPIスキーマ、クライアントとAPIスキーマ、クライアントとマイグレーションスクリプトの関係を理解しています。クラスターの構成要素目的ドキュメント目的ドキュメントは、コミュニティ主導の開発を可能にし、促進するためのものです。これには以下が定義されています：究極の目標：クラスターが達成しようとする包括的な目標。使用されるトークン：クラスター内で利用される特定のトークン。このドキュメントはクラスターの作成時に公開され、その後は不変のままです。目的ドキュメントに記載された究極の目標はシステム的な機能を持ちませんが、コミュニティはこのドキュメントを基に機能の改善や追加を行います。 APIスキーマ APIスキーマは、クライアントとサーバー間の通信方法を定義するプロトコルです。これは開発者が読める形式である必要があります。このスキーマに従うことで、異なる開発者が作成したクライアントとサーバーが相互に通信できます。 APIスキーマ間の互換性がある場合、サーバーとクライアントは複数のWeb APIスキーマをサポートできます。マイグレーションスクリプトマイグレーションスクリプトは、クライアントが特定のデータモデルを持つことを前提としています。これにより、同じマイグレーションスクリプトを参照するクライアント間でのデータ移行と同期が可能になります。クライアントクライアントは、HTMLやJavaScriptなどの静的コンテンツで構成されており、特定のインターネット接続や特定のサーバーに依存せずに独立して動作できます。クライアントは、ユーザーが指定した宛先としか通信できません。特定のサーバーに依存するように実装してはいけません。クライアントは、ユーザーがサーバーに送信またはサーバーから受信するデータをキャッシュできます。特定のマイグレーションスクリプトを指定し、そのスクリプトを実行することでデータ移行が可能なデータ構造でデータをキャッシュしなければなりません。サーバーサーバーは、APIスキーマに準拠したAPIを提供します。APIスキーマで定義できるあらゆる機能を提供できます。バージョン管理ポータブルウェブでは、クラスターは単一のアプリケーション単位ですが、使用するコンポーネントによって異なる動作をします。誰でもマイグレーションスクリプト、APIスキーマ、クライアント、サーバーなどのコンポーネントを作成できるため、クラスター内にさまざまなバージョンが共存します。...

安冨モデルの紹介

はじめに安冨歩さんという方がいらっしゃいます。私は大学生になって間もない頃、図書館で「経済学の船出」を読み、こんな経済学者がいるのかと衝撃を受けたのですが、今日はそんな経済学者が作った貨幣の生成や崩壊のMAS（マルチエージェントシミュレーション）モデルを紹介します。モデル自体は1995年に論文「The emergence and collapse of money」で発表され、2000年には書籍として「貨幣の複雑性: 生成と崩壊の理論」（以降、書籍）が出版されています（書籍は出版社が潰れたため現在は中古市場で高値取引されています）。モデルは拡張性が高く、暗号通貨や基軸通貨の分析などの研究でベースとして現在も利用されています（応用例は別記事で紹介します）。モデルは3種類ありますが、いずれも人工的な市場（しじょう）というよりも人工的な市場（いちば）に近いモデルです。 3つのモデルから、段階的に貨幣の生成や崩壊の設定を探っています。最終的なモデル（進化的モデル）ではエージェントのシンプルな行動ルール（欲求、需要、生産、消費、情報交換、戦略の変更）から貨幣の生成や崩壊という複雑な現象を再現しています。ここでは基本的に書籍を参照して、モデルのみを紹介します（背景の思想等については別の記事で紹介します）。詳細を知りたい方は書籍をあたってください。モデルの種類書籍では、物々交換のモデル（欲望の二重一致の困難さを確認）貨幣的交換のモデル（貨幣の生成メカニズムを確認）進化的モデル（貨幣の生成と崩壊メカニズムを確認）という順序で発展的にモデルを作成しています。以下、それぞれについて紹介します。共通する設定その前にモデルで共通する設定を紹介します。 1ターンで全てのエージェントはそれぞれ1回ずつ需要→交換→消費・生産のサイクルを実行するあるエージェントが生産する商品は1種類で、シミュレーションの途中でエージェントが生産する商品は変化しないエージェントは、最初に自分が生産した商品を1つ所有している各エージェントは最初に自分が欲求する商品を決めるエージェントは、自分が生産した商品は欲求しないエージェントは以下のパラメータを持ちます。 $$Agent_i = (w_i, p_i, \boldsymbol{h_i}, \boldsymbol{d_i}, u_i)$$ $w$ - 欲求する商品：エージェントが消費したい対象で、所有する場合は消費ステップで全て消費する $p$ - 生産する商品：エージェントが生産する商品 $\boldsymbol{h}$ - 所有ベクトル：エージェントが持っている商品のベクトル $\boldsymbol{d}$ - 需要ベクトル：エージェントが消費したいと考えているかに関わらず需要している商品のベクトル $u$ - 効用水準：所有している$w$を消費して増加する、エージェントの得点ここで、欲求と需要を区別していることに注意します。また、シミュレーションには以下のパラメータがあります。 $N$ - エージェント数 $C$ - 所有費（書籍では運送費ですが、モデルは距離的なロジックを持たないため所有としています） $P$ - 生産費物々交換モデルパラメータ書籍では、以下のパラメータが使用されています。 $N = 50$ $C = 0....

次世代Webに向けたムーブメントを整理する

はじめにこの記事は、現状のWebアーキテクチャの問題点を示し、それを解決せんとするムーブメントをまとめたものです。私はPortable WebというWebアーキテクチャを作りましたが、本稿はPortable Webを説明するための序章として書きます。そのため、本ブログの他の整理記事とは多少異なります（独自の解釈があったり、オピニオンが入っていたりします）。既存のWebアーキテクチャに対する問題意識と目標イントロ:「ElonMuskが狂ったらどうなる？」 Twitterは数億人が利用するWebサービスですが、そのWebサービスの命運がたった１人によって握られているというのは異常な事態と言えるでしょう。しかし、社会はTwitterが使いやすいという理由でTwitterを捨てません。社会はTwitterに依存してしまっているのです。 ElonMuskがTwitterを買収してから、次世代Webの必要性を世間の人々が納得してくれ易くなりました。次世代Webの必要性が伝わるために実際にWebが崩壊していくことが必要であるというのは、とても皮肉なことで、最近は喜ばしいのか悲しいのかよく分からない気持ちになります。例えるなら、システムが攻撃された後にセキュリティ対策を施すようなものです。ここで私は説明の簡易性のためにElonMuskを例に出している　―Twitterを媒介（メディア）としている―　だけであって、Twitterに限らずWeb全体がこのような状況です。 Web全体、つまり現状のWebアーキテクチャに問題があるです。本稿では、その問題と解決策を考えていきます。コラム：単一の主体ここでの単一の主体とは、個人のみならず株式会社やDAO（Decentralized Autonomous Organization）を含みます。というのは、株式会社やDAOであっても、最終的に投票などによって意思決定はA/Bのどちらか１つに決まるためです。複数の主体というのは、互いに独立に外部に影響を与える、複数の意思決定者です。主体の数は、その主体の内部的な意思決定構造には関係なく、外部に影響を与える意思決定者の数です。例えばタケノコとキノコがあった時に、ある個人がタケノコを選んだことと、ある会社がタケノコを選んだことは場からタケノコが１つ減ったという点では同じです。 Web2の問題点、それは解決できるか現在のWebアーキテクチャ（Web1~Web2）におけるWebサービスは「単一の主体が提供する、ブラウザを通じてアクセスできるアプリケーション」と定義できます。さらにアプリケーションは、「何らかの目的を持った機能の集合体」と定義できます。例えばFacebookは１つのWebサービスであり、単一の提供者はMeta社です。しかし、新しい技術（Fediverse等）の登場によって、必ずしもこの定義が当てはまらくなってきています。つまり、Webサービスが進化しているのです。本稿では、後で新たにWebサービスを定義しますが、それまでは上の定義を利用します。 Web2の問題点は、利用者、延いては社会がWebサービスに依存してしまっていることです。その原因としてデータロックインがあります。なぜWebサービスがデータロックインするかというと、利用者の流出を防ぎたいためです。利用者数が収益に直結することを考えるとそのような戦略になるのが自然だと思います。例えば、毎日Facebookの投稿をしたり、いいね！を押したり、知り合いと繋がりを持ったとして、それを数年繰り返すと膨大な量のデータになります。 Webサービスを乗り換える際はそれらのコンテンツを移行することに加えて、全ての知り合いが同時に乗り換えてくれなければ、移行先のWebサービスの効用は減ります。全ての知り合いが一斉に乗り換えるというのは理論上は可能でも現実的に不可能であって、それ故にデータロックインは強さを持つし、利用者はWebサービスに依存してしまうのです。ただし、もしデータが一部しか移行できないとしても移行先のWebサービスの効用が高いという（とても珍しい）状況では、利用者は依存を振り切って移行するでしょう。さて、Webサービスへの依存は利用者にとって悪い（ここでの「悪」は、あくまでも私の考える「悪」です）ことでしょうか？上述の定義では、悪いことになります。というのも、単一の主体が提供するものとして定義されているため、Webサービスの利用者はその単一の主体に隷属してしまうためです。実際、Twitterに生息している感受性の高いネットユーザーはElonMuskに隷属している　―ElonMuskの意思決定次第でアカウントがBANされる可能性もある（実際に起きている）し、目に触れるツイートも違ってくる（つまり考えに影響を及ぼす）―　と感じるのではないのでしょうか。もし単一のWebサービスが複数の主体から提供されている場合、利用者には提供者を選択する自由があり、それによって提供者に対する隷属から逃れられるかもしれません（私は逃れられると考えています）。したがって、Webサービスに依存することが悪いというより、むしろWebサービスを提供する主体に依存することが悪いのです。この悪（=提供者への隷属）を解決するための動向としては、「体制による反体制的な活動」と「無名の人々による反体制的な活動」に大別できます。前者は、例えばEUのデジタル市場法（後述します）があります。法律は自律した国民が選出した代理者が強制力のある法律を制定することによって、強制的に社会を変革するという発想です。後者はというと、例えばFediverse（後述します）などの新たなアーキテクチャです。アーキテクチャは、技術者（自律した個人・組織）が新たなシステムを作り、それが人々にとってより良いものであるなら、自然とそのシステムに移り変わるだろうという発想です。私はアーキテクチャの観点から考えています。法律は施行された時から社会に対し強制力を持ちますが、アーキテクチャは社会に対しオプション（選択可能性が確保される）になります。そのため、できることならアーキテクチャの方が良いと考えます。しかし、アーキテクチャで独占を変えられない地点まで行ってしまった場合は法律を作る正当性があると考えます。理想（目的）は、利用者がWebサービスの提供者に隷属している状態から脱却し、ある提供者の一存で利用者が右往左往されるのではなく、Webサービスの主権を利用者が持つことです。そのためには、誰でも提供者になることができ、かつ利用者が提供者を自由に選択できることが必要です。ここでの「自由に」というのは、利用者が乗り換える際に、その乗り換え先から同等以上の効用を得ることができるということです。データを伴わない移行などで、効用が下がった場合、それは不自由な選択です。例えるなら、居場所のない女性がDV彼氏に依存してしまう状況から、たくさんの男性がその女性にアプローチする状況が生まれ、より大切に扱ってくれる男性の所へ行くという感覚です。したがって、依存の原因であるデータロックインを回避し、誰でも特定のWebサービスを提供でき、かつ利用者（社会）が特定のWebサービス提供者に依存しないWebアーキテクチャを構築するのが目標になります。コラム：法律とアーキテクチャ法律とアーキテクチャの関係についてさらに詳しく知りたい方には、アーキテクチャと法がオススメです。数年前に興味で購入しました。読みやすいため、今でもたまに気軽に開きます。買ってよかったと思える書籍です。...

良い文章の書き方を整理する

はじめにみなさん、良い文章書いてますか？私自身、良い文章を書くにはどうしたら良いのだろうとか、そもそも良い文章とは何だろうと思う事が多々あります。本稿は、図書館にあった「文章の書き方」的な本を数冊読んで、良さそうな項目を抽出して自分なりの言葉でまとめたものです。良さそうな項目というのは、複数の本に書いてある項目や直感（経験を含む）的に良いと思った項目です。読んだ本は最後にある参考文献にまとめてます。本稿は「本→ノートに１ページでまとめる→記事」という流れで書いているため、不完全な場合があります。本稿は良い文章を書くための方法を、いつでもサッと見返せるように整理することを目的としています。ここでの良い文章とは、読者にあまり負担をかけず、何かを論理的にハッキリと伝えられるものを指します。文章以前の心構え良い文章を書くために必要な心構えとして、次のようなものがあります。情報は「分かりやすさ」でラッピングして相手に届けなければいけないメンタルモデルを意識する書いて良いのは事実と意見のみ。お気持ち表明はTwitterでどうぞハッキリと伝える伝えるために必要十分な情報を書く情報はどんなに有益だろうと、相手に伝わらなくては意味がありません。絶えず情報爆発し続ける現代では、たとえ相手に興味を持ってもらえたとしても相手に伝わらない文章は後回しにされ、読んでもらえない可能性が大きいです。したがって、文章を書く際の最重要項目は分かりやすさです。そして分かりやすさを作るには、誰を読者と想定するのか、読者の予備知識はどの程度か、読者は文章に何を期待・要求しているのか考え、それに適合させる必要があります。文学的文章であれば表現としてまかり通ると思いますが、それ以外では構成や文体などを相手に合わせなければいけません。文章が言わんとすることは、読者の短期記憶に収納されます。人間の短期記憶には限りがあります。もし最初に○○についての文章だと分かっていたら、読者は事前に関連する情報を活性化します。メンタルモデルの構築に成功した場合、話が通じやすくなります。というのは、読者と前提を共有できているためです。逆に失敗した場合は新しい言語をその言語の原文のみで学ぶようなもので、単純なことを言っていても難解になります。書いてよいのは事実と、そこから導かれる意見です。根拠のない意見、すなわち心情を書いてはいけません。心情を書いた瞬間、その文章はポエムになります。また、事実と意見は峻別する必要があります。もし事実と意見が混同されていれば、読者が混乱するどころか、その文章の信頼性は低下します。日本語は曖昧な言語です。例えば、主語を省略したり自分の意見なのに受動態を使ったりすることが多々あります。読者に行間を読ませてはいけませんし、読んでもらえると考えて文章を書くのは楽観的すぎます。私は以前まで行間に頼った文章を書いていました（楽観的すぎました）が、読者がよほど作者を好きであるか重要だと感じていない限り、行間なんて読んでもらえませんし、直接的に書いてある方が明瞭で分かりやすいです。また論理的に何かを伝えるには、読者がどんな文章の読み方をしても誤読できないように書く必要があります。もし文章の読み方次第で色々な解釈があると言えるなら、それは責任回避で、何か言っているようでほとんど何も言ってないのと同等です。文章は目的があって書かれます。目的のない文章は（人間が書くもののなかでは）ありません。伝えるために必要な情報は書くべきですし、不要な情報は削るべきです。では、書く作業をどのように進めたら必要十分な情報を書けるのでしょうか。文章を書く際は１つの大きな目的を定め、その目的のための全体の骨格を作ります。そして骨格が目的を達成するために必要充分であるかを熟考します。骨格が完成したら、骨格の構成要素ごとの目標を達成するためだけに文章を書きます。骨格の構成要素ごとの目標に不要な文章を書いてはいけませんし、論理が飛躍した文章や厚みのない文章を書いてもいけません。コラム：起承転結物語の伝え方に起承転結がありますが、この「転」は、何かを論理的に伝える文章に向きません。起承と転があまりにも違いすぎて、読者が混乱してしまいます。文章内での刺激的な変化は不要で、「あれ？もう終わっちゃったよ」程度が良いです。パラグラフライティングパラグラフライティングは良い文章を書くのに最も最適な方法です。パラグラフライティングとは、トピックセンテンスとサポーティングセンテンスによって構成される、世界で広く使われている書く技術です。パラグラフライティングは以下のような特徴があります。トピックセンテンスでパラグラフの要約、サポーティングセンテンスで詳細を記述文章はパラグラフを最小単位として構成される１つのパラグラフで１つのメッセージを伝える書いた内容が、それまでに書いてきた内容のみで理解できるよう構成するトピックセンテンスは、パラグラフの最初に一文でそのパラグラフの要約を書きます。文書の各パラグラフのトピックセンテンスだけ読んで、どんな内容が書かれてあるか大まかに分かるのがベストです。こうすることで、読者は飛ばし読みできます。つまり読者が知っている内容を飛ばしたり、興味のある箇所だけつまみ食いできるようになります。パラグラフライティングで書かれた文章は、文単位ではなくパラフラフ単位で構成されます。文単位で構成された文章では、形式が変則的になりがちで、形式と論理のかたまりが必ずしも一致しません。その結果、分かりにくくなります。対してパラグラフが単位であれば、形式が決まっているため、読者は論理が掴みやすいです。パラグラフは最小単位なので、メッセージは１つだけ伝えるようにしましょう。１つのメッセージを伝えるためだけにそのパラグラフを書き、パラグラフを繋げることによって複数のメッセージを伝えるようにします。パラグラフでは扱う話題+主張を１セットとしますが、主張が２つある場合は複数のパラグラフに区切ります。つまり、（扱う話題+主張）+（扱う話題+主張）です。また、パラグラフは３~８文にするべきです。というのは、短すぎると単位が文となり、長すぎると読みにくいためです（長い場合は複数のメッセージが入っている可能性があります）。...

クリプトエコノミクスを整理する

はじめに私は以前作った作品に、共創のためのインセンティブ設計としてクリプトエコノミクスを組み込みました。しかし今振り返ると、クリプトエコノミクスって何だっけ？となって混乱したので整理します。クリプトエコノミクスが生まれたきっかけ（背景）、クリプトエコノミクスとは何であるかという大まかな流れでクリプトエコノミクスを整理します。また、最後には私なりのクリプトエコノミクスを定義します（まとめ）。詳細に入る前に、クリプトエコノミクスをざっと掴んでおきましょう。ウィーン大学のShermin Voshmgirらは以下のような定義をしています。インターネット上にある他の情報を鑑みても、この定義は一般的な定義となっていると思います。 Cryptoeconomics is an emerging field of economic coordination games in cryptographically secured peer-to-peer networks. Foundations of Cryptoeconomic Systems クリプトエコノミクスが生まれたきっかけ（背景）クリプトエコノミクスを理解するには、最初にクリプトエコノミクスが組み込まれたシステムがどのようなもので、どのような課題があったかを知るのが良い方法です。ここでは最初にクリプトエコノミクスが組み込まれたシステムであるBitcoinの目的、それを実現する難しさ、その解決策を記します。せっかちな方は、次の章まで飛ばして頂いても結構です。 Bitcoinの目的ですが、Bitcoin論文のIntroductionには、最初に以下のような記述があります。 Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model....

Decentralized SSO

Decentralized SSO Decentralized SSOは、SSOを分権化することで、セキュリティを向上させる仕組み・ブラウザ拡張のソフトウェアです。この作品は私が普通科の高校生だった頃（2020の春頃）に制作し、U-22プロコンBest40の評価を頂いた処女作（Best40程度では処女作に入らないかもしれませんが）です。 U-22には、Aoiという作品名で提出しています。背景皆さまご存じの通り、SSO(Single Sign On)はその利便性から、広く普及しています。しかし広い意味でのセキュリティ的な懸念があります。つまり、SSOを提供する主体（Trusted Party）が絶対的な権威となり、利用者の正当性を保障するということです。 SSOを利用する主体（Relying Party）は利用者の正当性を根拠なく信じます。この正当性というのは、利用者がBotでないこと、利用者が本人であること、利用者が正当な目的で利用していることなどです。一つ例を挙げましょう。 TwitterはSSOを提供しています。もしElonMuskが狂ってしまい、TwitterのSSOでなんらかの不正な認証が行われるとしたら？世の中のサービスは大混乱です。 TrustedPartyが保障する利用者の正当性についての情報がより信頼できればRelying Party側はハッピーです。では、どうすれば情報の信頼性が向上するのでしょうか？解決策複数のTrusted Partyから利用者の正当性に関する情報を得ることが出来れば、情報の信頼性を高めることができます。これが大きな方針です。 Decentralized SSOでは、利用者のアカウントを公開鍵として表現します。 Decentralized SSOの利用プロセスはシンプルで、次のようなものです。利用者は、Decentralized SSOを利用するTrusted Partyにアクセスし、会員登録を行う。利用者は、Trusted Partyの内部アカウントと拡張機能のアカウントを紐づけます。利用者は、この1~2を他のTrusted Partyでも同様に行います。ただし、拡張機能側のアカウントは１つです。そして、とあるRelying Partyを利用し始めるとき、その公開鍵利用してログインできます。 Relying Partyは自分が比較的信頼する複数のTrustedPartyから、利用者の公開鍵のハッシュ値をもとにして利用者の正当性を確認します。これだけです。これだけで、SSOの信頼性が向上します。公開鍵を利用するということがポイントですね。この方法の問題点ただしこれにはいくつかの問題点があります。公開鍵とサービス内部のアカウントを紐づけることで、より多くのサービスに渡って利用者がプロファイリングされる。統一された規格を利用する必要があるが、標準化のID（ Internet Draft ）提出などを行っていない。ただし、Metamaskなどのブラウザウォレットの普及によって、2020年ほど普及のハードルは高くないと思います。これらの問題点が解決されることを願いつつ、私は今日も自分の興味に従い他の領域に足を踏み入れます。いつかこの作品にひょっこり戻ってくるかもしれません。