ナンクロで数字探しを省くためのツール作成
最近漢字ナンクロをよく解いたのだが、問題が大きくなってくると熟語を考えるより数字を探す時間の方が長くなってしまい面倒だった。それを解消するためこちらのようなツールを作った。
https://y-kamiya.github.io/nankuro-editor/public/
使い方
repo上にexamplesとして例となるデータをおいたので、同じようにjsonファイルを作ってブラウザ上で読み込めばOK
{
"data": [
[2,4,1,3,4],
[4,0,2,4,0],
[2,2,0,2,5],
[0,5,3,0,1],
[1,3,2,5,3]
]
}
上のようなデータをloadすると下のような画面になる
上部に答えを入れるテーブルがあり、focusすれば問題中の対応する部分もわかる。
解いている間に間違って戻るなどボタンなど押してしまうとすべてクリアされてしまうので注意。save fileをすれば答えも含めてjsonとして保存できるので、解きつつたまにsaveしておくことを推奨。
ちなみに、問題が大きい場合jsonデータを作るのが大変なので、imageファイルから必要なデータを読み取ってjsonするツールを別途作成中。
実装
reactで実装。tableの各セルの値に合わせて処理を変える必要があるが、reactだとその部分をcomponentとして分離しておけるので相性よく感じた。また、
- 入力に応じてイベントを飛ばす
- イベントに応じてstoreの処理
- storeの状態に応じて表示分け
とすべてを分離して書けるので各々をすっきりと書くことができ、ロジックを考える上でも混乱することなく進められたのもよい。
開発環境についてはホストの環境上にいろいろinstallするのを避けたかったためdockerを利用。
docker-composeは特に使う必要なかったのだが、使うimageやオプションを設定ファイルとして書いておけるというメリットがあるので使ってみた。
docker container内でcpuminerをビルド(bitzeny)
cpuminerでマイニングするためminerdをビルド。その際ごちゃごちゃさせたくなかったのでdockerのコンテナでやったのでメモ。ちなみにビルドしたのは最近話題になっているbitzeny用のcpuminer。
このqiitaの通りで問題なく苦労するとこはなかった。 https://qiita.com/s_ktmr/items/f46c0d814a340407cf06
Dockerfileはこんな感じ
FROM ubuntu:16.04 RUN apt-get update -y \ && apt-get install -y git automake build-essential libcurl4-openssl-dev RUN git clone https://github.com/bitzeny/cpuminer.git WORKDIR cpuminer RUN ./autogen.sh \ && ./configure CFLAGS="-O3 -march=native -funroll-loops -fomit-frame-pointer" \ && make \ && make install
こちらのrepoにあげてある。 https://github.com/y-kamiya/docker-cpuminer-bitzeny
↑のDockerfileのあるディレクトリで以下のようにすればminerdが使える
$ docker build -t image_name . $ docker run --rm -it image_name /bin/bash # minerd <必要な引数>
とりあえず動かしてみたくらいなので、dockerhubには上げてない。もう少しちゃんと書いたら上げるかも。
minerd自体の使い方はこちらの通り。poolへの登録についてなども書いてある。 https://cryptomamiya.com/index.php/2017/10/30/post-250/
~ ~ ~ ~ ~ ~ ~
rippleで使われるコンセンサスアルゴリズム
仮想通貨であるrippleで用いられるコンセンサスアルゴリズムについて、white paperを読んでみたのでわかったことをメモ。
まとめ
メモ
過去の研究でわかったこと
- 一つのfault nodeが存在するだけであっても、一つのconsensusに収束しない可能性は常にある
- 時間ベースのリミット（または収束しない状態での繰り返し回数最大値）が必要
- ビザンチン将軍問題＝ネットワーク内の33%以上がfaultだった場合には正しいコンセンサスは得られない（同期の場合）
- 非同期の場合でも2008年の論文により33%の耐性が作れること示された（ネットワークに追加の制約あるけど）
ripple algorithmではヒューリスティックな方法でコンセンサスを一意に保つようにした
- 各ノードが応答する時間として最低2秒が与えられる
- これによって多少ネットワークが遅延したノードでもコンセンサスプロセスに参加できる
- どのノードがどんな投票をしたかは台帳に記録されるため、悪い挙動をしたノードを検出できる
- 信頼できるノードを記録したUNLが各ノードに与えられる
- UNLのうちアクティブなノードの数を監視し、一定の数を下回った場合はトランザクションの処理を一時的に止める
- その状態で処理を進めると一つのコンセンサスに収束しないことがあるため
一意なコンセンサスに収束するための条件
個々のノードは信頼できる他のノードのリストを持っている（UNL）
response timeをモニタすることで、基準より反応の遅いノードをUNLから削除した上でコンセンサスを取る。
20%以下のfaultノードかつequation3を満たす場合に有限時間でコンセンサスは収束
|UNLi ∩ UNLj| ≥ 1/5 * max(|UNLi |,|UNLj |)∀i, j - (3)
すべてのi,jの組み合わせにおいて、node i, node jのUNLの重なる部分の数がどちらかのUNLの1/5以上であること
attackerによる攻撃の意味を少なくさせるための施策について
以下のコストを発生させることでattackerからの攻撃を防ぐ
- rippleのaccount作成には20xrpが必要
- transaction feeとして0.00001xrpかかる
どちらも正常に使う分には無視できるレベルのコスト。しかし、DoS攻撃などしようとした場合にはコストがかさむことになる。
