ルール

参加者は、開催者が隠したお宝を見つけることで、保持しているERC20トークンを増やしていく。

参加者

• 開催前において、$n$人の参加者を予定しているとし、それぞれ$P_i$と表す $(i\in \{1,\dots ,n\})$。
• 開催中に参加者を増やすことができる。

お宝

• 開催前において、$m$個のお宝を予定しているとし、それぞれ$T_j$と表す $(j\in \{1,\dots ,m\})$。
• お宝は、QRコードなどの、十分な長さのバイト列を表現できるものとする。
• 開催中にお宝を増やすことができる。

ゲームの流れ

開催前

1. 各参加者$P_i$は、ゲームで使用するアドレス$a_i$を生成して公開する。
2. 開催者は、各お宝$T_j$に対応する十分な長さのバイト列$b_j$を生成し、それを記載したものを隠す。
3. 開催者は、$\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(b_j||a_i\right)$を計算し、末尾20バイトをアドレス$s_{ij}$とする $((i,j)\in \{1,\dots ,n\}\times \{1,\dots ,m\})$。
4. 開催者は、$n\times m$行列${\left[\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(s_{ij}\right)\right]}_{i\le n,j\le m}$を引数として、トークンコントラクトを生成する。
5. トークンコントラクトは、行列${\left[\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(s_{ij}\right)\right]}_{i\le n,j\le m}$をストレージに保存する。

開催中

• トークンコントラクトは、$a_i$から$t$へトークンを移転するとき、$\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256(t)$が行列の第$i$行に存在するならば、$a_i$に報酬トークンを与える。
• お宝$T_j$を発見した参加者$P_i$は、$s_{ij}$を計算することができ、$a_i$から$s_{ij}$へトークンを送り報酬を得る。
• 開催者は、参加者を増やすとき、$n^{\prime }$人の新規参加者のアドレス$a_i^{\prime }$と$m$個の既存お宝のバイト列$b_j$から、$\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(b_j||a_i^{\prime }\right)$を計算し、末尾20バイトをアドレス$s_{ij}^{\prime }$とする $((i,j)\in \{1,\dots ,n^{\prime }\}\times \{1,\dots ,m\})$。そして、$n^{\prime }\times m$行列${\left[\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(s_{ij}^{\prime }\right)\right]}_{i\le n^{\prime },j\le m}$をトークンコントラクトに送信する。トークンコントラクトは、新規行列を既存行列に合成して保存する。
• 開催者は、お宝を増やすとき、$n$人の既存参加者のアドレス$a_i$と$m^{\prime }$個の新規お宝のバイト列$b_j^{\prime }$から、$\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(b_j^{\prime }||a_i\right)$を計算し、末尾20バイトをアドレス$s_{ij}^{\prime }$とする $((i,j)\in \{1,\dots ,n\}\times \{1,\dots ,m^{\prime }\})$。そして、$n\times m^{\prime }$行列${\left[\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(s_{ij}^{\prime }\right)\right]}_{i\le n,j\le m^{\prime }}$をトークンコントラクトに送信する。トークンコントラクトは、新規行列を既存行列に合成して保存する。

考えられる戦略と耐性

• 参加者は、公開情報を用いて報酬を得ることができない。
  • 参加者$P_e$は、トークンコントラクトが保存している行列の第$e$行を知っても、Keccak256の弱衝突耐性により、トークンを送ると報酬を得られるアドレスを計算することができない。
  • 参加者$P_e$は、参加者$P_i$のトークン移転トランザクションを傍受し$s_{ij}$を知っても、Keccak256の原像攻撃困難性により、$s_{ej}$を計算することができない。
• 参加者は、お宝を発見したならば、その報酬の内容を事前に知ることができる。
  • 参加者$P_i$は、お宝$T_x$を発見したとき、$x$が$1,\dots ,m$のうちのどれかを直ちに知ることはできない。しかし、$a_i$と$b_x$を用いて$s_{ix}$を計算し、トークンコントラクトが保存している行列で$\mathrm{K}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256\left(s_{ix}\right)$が存在する列を探すことができる。それが第$j$列だったとすれば、$x=j$を知ることができる。
  • 全てのお宝は正の報酬を持っていることが保証されている場合、これは問題にならない。
  • この戦略を防ぎたいのであれば、全てのお宝は先着1名にのみ報酬を与えることとすればよい。 2018-11-06訂正
• 参加者は、レインボーテーブル攻撃を行うことができる。
  • ゆえに、お宝のバイト列は十分長くする必要がある。
• 参加者は、複数人を装って登録することで有利になることができる。
  • お宝の報酬を何度も得て、1つのアドレスに集約することができる。
  • この戦略を防ぎたいのであれば、全てのお宝は先着1名にのみ報酬を与えることとするか、開催者が登録時に本人確認をすればよい。
• 複数人の参加者が結託して有利になることができる。
  • お宝のバイト列を共有することができる。
  • この戦略を防ぎたいのであれば、全てのお宝は先着1名にのみ報酬を与えることとすればよい。

PoC

https://github.com/AzonTi/TrueTECH

参考

Bitcoinによる新しいCapture The Flag（CTF）

某イベント、トークンに価値をつけないんだったら、そもそもEthereumでやる必要ある？