Monacard完全非中央集権化構想

この記事では画像のアップロード仕様について話します。 現在の仕様ではcard.mona.jpを必ず通さないとMonacardの画像をアップロードできないことになっています。モナパレットを使っているときも裏で必ずcard.mona.jpのサーバーにアップロードしています。 現在のメリット ・card.mona.jpの管理人がまともである限りは安定して使用できる。 デメリット ・card.mona.jpの管理人が変な事をしていても従わざるを得ない。・管理人が行方不明になった場合に新規カードが発行ができなくなる。もしくは第三者が類似サービスを立ち上げるのに時間がかかる。 モナカードは2.0化によって非中央集権化を進めましたが、実は画像の運用については現在も中央集権的です。ここを非中央集権化しなかった理由は画像へのアクセス速度や寿命が不安定になりユーザーが著しく使いにくくなると考えたからです。最近のNFTブームの影響もあって波はありますがモナカードユーザーは増える傾向にあります。ここまで大きく育ったサービスをcard.mona.jpに依存させたまま不意に終わらせてしまうようなことがないように、画像部分についての構想も文章化しておきたいと思います。非中央集権化と画像の安定した運用の両立を考えた構想です。 画像非中央集権化構想 策定した仕様を満たした画像アップロードサーバーをMonacard2.0画像準拠サーバーとし、誰でもMonacard2.0画像準拠サーバーを公開, 運用できるようにする構想です。 基本的な仕様 ・アップロード用のAPIを用意すること・IPFSにファイルを設置すること・画像についての情報をAPIとして公開すること・策定された画像についての規約について同意しこの規約を表示すること・規約違反の画像を検閲すること・画像へアクセスするためのURLを公開すること(http(s)でアクセスできるもの)・画像が消えないようにどのような構成でバックアップを行っているか明示すること・アップロード時の利用料は任意で決めることができる今のところ思い付きですがこんな感じの共通の仕様を作ることで複数のサーバーが立ち上がっても最低限の動きは保証されるはずです。サーバーの運営者はアップロードされた画像を消えにくい状態にする努力義務が発生します。ユーザーはバックアップの構成や運営者の信用を見てどこを使うか判断することができます。非中央集権化して選択肢が増えるということは良いことばかりのような気がしますがそうではありません。この構想が正式な仕様となってサーバーを運用する方が出てきて半分の新規カードの画像がそちら経由でアップロードされたとします。2年後、このサーバーの運営者が飽きてサーバーを放置あるいは解約、さらに不運にもIPFSからも参照できなくなり画像が行方不明になってしまうかもしれません。その場合新規モナカードが表示されなくなり電子ごみになる可能性があります。自分で言うのもあれですが、card.mona.jpは5年近くある程度安定して運営されてます。誰も見向きもしなくなった期間も最低限の保守はしていました。7年以上いろんな暗号通貨系のサービスを見てきましたがこのように長い期間生き残ることは稀です。長い間保守運営できる人は稀です。そう考えると信頼できるサーバーを選択すること自体がなかなか難しいということになります。長々と書いてきましたが、構想はあるのですがデメリットもあるためずっと先送りにし続けている状態です。これから先もずっと先送りしたいのですがそうも言っていられない状況がくるかもしれないのでいろんな人に共有するために記事にしてみました。この構想はこの後書こうと思っているモナカード有料化構想とセットですので気になる人はそっちも読んでみてください。 厳しいご意見、提案、質問などお待ちしてます。

ECDSAのアダプター署名とDLCへの応用

先日の読書会にて様々なScriptless Scriptの手法についての解説があり、中でも「Payment points without 2p-ECDSA or Schnorr」と呼ばれる手法とそのDLCへの活用事例が面白かったので、それについて復習も兼ねて紹介したいと思います。 ペイメントポイントについては以前の記事で解説しましたが、ライトニングネットワークのマルチホップペイメントではHTLCと呼ばれるコントラクトを使うことで複数ノードを中継してコインを送金しています。しかし、このHTLCでは中継ノード全員に同じシークレットが行き渡ってしまい、それにより送金経路が明らかになったり、中継ノードが結託することで攻撃ができてしまう欠点がありました。ペイメントポイントを使うことで、中継ノードそれぞれに個別のシークレット情報を渡すことが可能となり、プライバシー向上や攻撃への対処ができることを解説しました。このペイメントポイントはアダプター署名を使用していますが、シュノア署名の導入が必要であったり、既存のECDSAを使う場合でも2者間で暗号化した署名を交換しあう必要があり(これを2party ECDSA、2p-ECDSAと呼ぶ)、複雑になるという難点があります。 そこで登場したのが、2p-ECDSAやシュノア署名を使わずにアダプター署名(Scriptless Script)を実現する方法「Payment points without 2p-ECDSA or Schnorr」です。この手法はOP_CHECKMULTISIGを使うので、完全なScriptless Scriptではありませんが、既存のビットコインブロックチェーン上で実現ができます。そしてこの手法をDLCへ応用することで、従来のDLCで想定されていたトランザクションをシンプルにすることができます。以前の記事でDLCの実装ソフトNDLCについて紹介した時、なぜアダプター署名を使う必要があるのか疑問でしたが、その答えがまさにこれでした。 Payment points without 2p-ECDSA or Schnorr アリスはボブが公開情報Tに対するシークレットtを公開すれば、1BTCを送金するという例をとって解説します。やりとりの流れは以下の通りです。 お互いの公開鍵AとBを使い2 of 2マルチシグアドレス(P2SH)を作成し、そのアドレスへアリスが1BTCを送金する。 アリスはボブの公開情報Tを使って公開鍵Aに対するアダプター署名を作成し、ボブへ渡す。 ボブはtを使ってアダプター署名から公開鍵Aに対するECDSAの署名sAを復元し、自身の公開鍵Bに対する署名sBを作成する。そして署名sAとsBを使ってマルチシグアドレスのBTCを回収する。 アリスは3でブロードキャストされたトランザクションを使うことでシークレットtを取得できる。 まずはECDSAの署名の計算式を思い出してみましょう。 ECDSAの署名 ----------------------------------- 秘密鍵    k 公開鍵    P = k * G メッセージ  m ランダムな値 r        R = r * G ----------------------------------- 計算式    s = (H(m) + R*k)/r 署名     (R, s) 上記フローの2番目では、アリスはボブの公開情報Tを使い、以下のアダプター署名②の計算をしています。 アリスのECDSA署名 sA = (H(m) + R*k)/r アリスのアダプター署名 s' = (H(m) + R*t*k)/r ・・・①    = (H(m) + r*T*k)/r ・・・② アダプター署名の復号 sA = s'/t ①のtはボブのみが知るシーク

バッジャー君

Spotlight

SNS platform for distributing digital content using Bitcoin. Each piece of content can be sold or purchased for as little as one $0.01 in Bitcoin, making it a fun place to start for both readers and creators.

Sign up
Search spotlight

Reckless ads

ads here

Trending Stories