Storjの1年間運用結果 & HDDマイニングの件

  • POSTS
⚠この記事はブログ移転前のアーカイブです いつの間にかStorjを運用して1年が経過していた。 ニュースではマイニング需要でGPUが絶望的な在庫枯渇を起こしているが、HDDを用いたマイニング(=ブロックチェーン上の取引承認)を行う通貨が登場したらしく HDDもその波に飲み込まれてしまい値上がりを続けている。 StorjはHDDマイニングなのか StorjはHDDを用いたマイニングのように見えるが、全く違うもので、クラウドストレージのスペースと冗長性を確保するために、世界中のStrojオーナーがHDDのスペースを貸し出しと管理の報酬としてStorjを受け取っている。これはEthereumのブロックチェーン上で取引されている。 Storjを開発しているTardigradeは、Storjを発行することによって資金調達できるし、法定通貨を持たずともHDD貸し出しをしているオーナーに報酬を支払うことができる。これはSiaコインも同じ考え方で、PCリソースを貸し出す代わりの報酬として仮想通貨を受け取っている。ただし、Siaは独自のブロックチェーンをもっていて、マイニング自体は別で行っている。 一方、HDD在庫で話題のChiaは、どうやらビジネスとしてHDDを貸し出すというのではなく、コンセンサスアルゴリズムとしてHDDのスペースを確保する仕組みを採用しているようだ。これは別に初めての試みというわけではなく、Burst コインがパイオニアだ。 1年間の運用結果 過去記事では2ノード立てたと言っているが、余ったディスクがまだあったので今は3ノードになっている。 2月報酬分までEthのメインチェーン上で支払っていたが、当時は圧倒的な手数料高騰で3月報酬分からzksyncというL2 paymentを使用して支払いが行われている。メインチェーンでは何度かETHに両替したため、総受け取りはStorjは約348.3 Storj だ。直近でStorjが高騰したため、相当儲かっているように見えるがそこまでインパクトのある報酬がもらえているわけではない。(ガチホしとけばよかったと深く後悔しているところ) 以下は3ノード分の専有量  ノード1:2020/3から2TBで、途中から8TBに換装 ノード2: 2020/4から運用 ノード3: 2021/1から運用 最近は流入量がかなり減ってきており、TB級のノードは容量が埋まるまで1年以上かかりそうだ。そもそも、S3互換とはいえBackblazeやwasabiなどの格安事業者がすでにあるため、価格競争が難しいのだろう。 現状HDDを買い占めてノードを乱立させてもペイするまでは程遠い。 Burstや、Siaのほうが儲かるかは不明だが、Chia(XCH)に関してはまだどこの取引所にも上場していないという問題(なのにXCH=$20としてマイニング計算を行っているらしい…)があり、またPoS(Proof of Stakes)などのより電力を消費しないコンセンサスアルゴリズムがある中、今これをローンチするというのは将来性に疑問が残る。そもそもHDDを製造している時点でコストがかかっているのだから・・・ とはいえマイニングは先行者利益要素が強いので余っているパーツがあれば参加してみてもいいと思う。どの通貨においても現在の価格とコインの報酬で計算するのはあまりペイできないように見えるので、報酬はホールドしてキャピタルゲインを狙うのがいいと思う。  

MokiboをiPadOSでうまく扱うためのコツ

  • POSTS
⚠この記事はブログ移転前のアーカイブです 最近Mokiboを買った。Mokiboはキーボード表面がタッチパッドになっているBluetoothキーボードのこと 購入前にTwitterやYouTubeで具合を確認していて、どうもクセの強い商品なのは知っていたのですが、実際触ってみると予想以上にクセが強かったです。 具体的には「キー配置」「キーピッチ」「スクロール仕様」「iPadOSの未熟さ」です。やはりWindowsやmacOSと同じように操作することはできませんでした ですが慣れでどうにかなる部分もありました。 スクロール仕様はかなりきついです。logicoolのTouch Keyboad Folioは純正キーボードと同様にジェスチャーや滑らかなスクロールができるようになっています。対してMokibo はマウス接続したような感じで、荒い分解能でスクロールし始めます。しかも慣性付きです。ちょっとスクロールしたと思いきや、なかなかスクロールせず重たい動作をすることがあります。 これは予想ですが、スマートコネクタを使用するしないで変わってくる可能性があります。例えば、Bluetoothでタッチパッドとキーボードを搭載した製品はことごとくスクロールがかくつくという欠点を抱えています。 これらの製品のスクロールは、マウスホイールをエミュレータしているだけなので、「一定の速さで指を動かすこと」と、「スクロールが止まるまで指を離さない」ことで対策できます。3本指のジェスチャーでもそうです。上記の2点さえ気をつけておけばそこそこ快適に使えます。 Logicoolのキーボードが正直最適解なのですが、私はタブレット状態で漫画を読んだり絵を描いたりするのでMokiboが必要に応じて使えるので最適解でした。 アップデートでどうにかして欲しいのですがOSの制約もありそうですし、日本代理店もアップデートの公開遅いしあまり期待できません。 ちなみにUS配列のキーボードは公式から6月のファームウェアを落とせるので、試しに日本語配列モデルに適用したのですがあまり動作に改善は見られませんでした。 なんだかんだ言っておすすめです。Mokibo

Storjノードを2つに増やした

  • POSTS
⚠この記事はブログ移転前のアーカイブです 約1ヶ月ちょっと運用しているStorj。もともとHDDの交換を考えていた矢先に始めたので、ちょっと大きめのHDDに交換しました。 既存のノードストレージとはマウントが異なるのと、領域の拡張ではなくノードを増やすほうが望ましいらしいので、ノードを2台にしました。 同IPで複数ノード走っている場合はファイルが分散される フォーラムにあった内容ですが、元々可用性を考慮しているので同じ地域に同じファイルが降ってくる確率が低くなるように設計されいます。特に同じIPで複数ノード立ち上がっている場合、同じファイルが降ってくることはないそうです。(確認しようがありませんが)そうであれば、データの降ってくる傾向が変わるかなと思い、とりあえず2日動かしてみました。 1つめのノードは容量がいっぱいなので、今発生しているIngressは全て新規ストレージになります。例によって主な流入元はアメリカサテライトのsaltlakeになります。最大でも20Mbps程度となり、思ったより速度は出ないです。 また、既存ストレージで削除が走ったため一時的に2ノードでIngressが発生したのですが、このときは20Mbpsを最大に帯域を分け合うような挙動をしました。我が家のISPのスピードテストでは常に400Mbps出ているので、ちょっともったいないかなと思っていますが、逆にHDDに高負荷がかからないのでまあいいかな。 追記: Saltlake宛のスピードテストしないと意味ないなと思い、speedtest.netでやってみたが、それでももっと速度は出てもいいかな。サテライトがボトルネックなのか、地理的な問題と配信アルゴリズムでそうなっているのかは不明ですが。 新規HDDには実験の意味も込めてST8000DM004にしました。いまのところ全く問題なく、ノードが固まったりすることもないです。まあ20Mbpsですし。 新ノードに割り当てた容量は5TB。この調子だと埋まるのに1ヶ月程かかります。前回とは異なる挙動が見れるといいな

Storj を1ヶ月稼働させて気づいたことまとめ

  • POSTS
⚠この記事はブログ移転前のアーカイブです Tardigrade.io として正式稼働したStorjですが、1ヶ月動かして気付いたこと、フォーラムを覗いて気付いたことを可能な限りまとめました。 もくじ 1. ノードからみて Ingress は入力、Egressは出力 2. 地理的な優劣が顕著 3. そもそも顧客が少ない 4. 4月以降もテストデータの流入が続く 5. CPUをそこそこ使う 6. HDDは選ぶ 7. 専用ハードウェアは間違いなくペイしない 8. Nodeはアップデートが頻繁 9. サービスとして生き残れるか 1. ノードからみて Ingress は入力、Egressは出力 ノードオペレータからの視点と顧客の視点は異なります。SNO (Storage Node Operator) 視点でのデータの流れはIngress、Egressと表記されます。データがSNOに降ってくることをIngress、SNOから出力するデータをEgressとします。なお、帯域課金されるのはEgressのみです。 2. 地理的な優劣が顕著 これは、当然のことですが、提供するファイルピースは提供の先着したものに報酬が与えられる仕組みです。主なサービス地域である北米/ヨーロッパ以外のSNOは成功報酬がかなり低いです。Asia圏のサテライトも存在しますが、これはTardigrade.ioのサービス拡大次第といったところでしょうか。 3. そもそも顧客が少ない 昨年からテストでSNOとサテライトの稼働がありましたが、正式にサービスインしたのはごく最近です。顧客もかなり少ないでしょう。今までほとんどテストデータが流れ込んでいましたが、サービスインした3月はSNOに対する支払いが少なかったようです。メインで使用されているソルトレイクサテライトのVettingが頻繁にあるのに対して、ヨーロッパ、アジアなどの他のサテライトからのVettingが全く進まず現在20%程です。 4. 4月以降もテストデータの流入が続く 4月は初週はかなり少量のデータしか流入しませんでした。突然中旬から20Mbps程度のテストデータが流れ込んで、2TBに設定したディスクがあっというまにいっぱいになりました。フォーラムを見るとテストデータの入出力は継続するようです。本来であれば、顧客によるデータ入出力があるといいのですが。 5. CPUをそこそこ使う 常にデータの入出力がある(I/Oがビジーに近い)場合、CPUを結構使います。そのため、NASやRaspberry Piでは少々不利であるとForumに載っていました。 6. HDDは選ぶ 提供ストレージの99.9%がHDDを使用していると思うのですが、ここ最近台頭してきたSMR方式のHDDには注意が必要です。フォーラムにはSMR HDDを使用した場合、負荷が上昇してアップロードに失敗する現象が確認されています。活発な議論が交わされており、また今後SMRのHDDが普及してくることを考慮すると、対応してくれることを信じていますが、現状はSSDのキャッシュなど挟むことで軽減できそうです。

余ったHDDを貸し出して利益を得るStorj(Beta)をセットアップして儲かるか確かめる

  • POSTS
⚠この記事はブログ移転前のアーカイブです Storj(ストレージ)は、ユーザの余ったストレージ領域を貸し出すことにより、ユーザには格安でストレージ領域を提供し、貸し出し者には利益の一部を分配するサービス/システムの名称です。 今回は実際にHDDの一部領域を貸し出してみて、どの程度儲かるのか、継続してご報告していきたいと思います。 Windows、Linuxのプラットフォームがサポートされていますが、今回はUbuntu(Linux)上にDockerでインストールしていきます。 もくじ Storjとは? ストレージノードを構築してHDDを貸し出す 1. 利用登録 2. 初期セットアップ 3. セットアップ 4. ノードの起動 運用と報酬 1. 支払いはUSD換算のStorj 2. 本格的なファイルの流入はサテライトから承認を受ける必要がある。 3. Egressのファイル提供は早いもの勝ち 開始から一週間の状況 Storjとは? Amazon S3 API互換の分散型ストレージサービスです。世界中の余剰ストレージ領域を使用して、Amazon や Googleより格安にストレージ領域を提供しています。ファイルは暗号化と分割化されて世界中のノードへ配信されます。ノードには完全なファイルはなく、更にそれぞれ暗号化されているためセキュアですよということらしいです。 最近、そのStorjプラットフォームを利用したサービス、Tardigrade.ioがローンチしました。 https://tardigrade.io/ 主要ストレージサービスより格安であることがアピールされていますね。 Amazon(Tokyoリージョン)で ストレージ0.025USD/GB、転送料は0.114USD/GBなのでかなりの格安っぷりです。因みにStorjは転送料は0.045USD/GBです。 ストレージノードを構築してHDDを貸し出す それではいよいよ、構築していきたいと思います。今回、筆者が用意した環境はこちらです。 OS Linux (Ubuntu 16.04) HDD 1.

安全で小回りの効く高対話型Honeypotを作る

  • POSTS
⚠この記事はブログ移転前のアーカイブです 知っている人がこのアドベントカレンダーに投稿していたので、過去にやっていた研究の話をアウトプットしようと思い私も投稿します。 ただし、筆者はコンピュータ初心者であり、今回の内容もCSS2016に出したものなのでかなり古いです。あと、直前に書き始めたので内容がスカスカです。それでもよろしければお付き合いください。 もくじ 1. 高対話型がやりたい 2. Linuxコンテナを使う 3. アーキテクチャ 3.1 要件 3.2 ライフサイクル 4. 動かしてみた 5. 問題点 6. まとめ 1. 高対話型がやりたい 既にナンセンスな分類かもしれませんが、Honeypotは低対話型と高対話型に分けることができます。低対話型で代表的なのは、Kippoもとい後継のCowrieでしょう。実際に使ったことのある人ならわかりますが、SSH低対話型は侵入した攻撃者を観察しようとしてもコマンドの自由度や再現度が極端に低いため、思うように活動してくれないことがあります。また、Kippo、Cowrieはハニーポットであることが判別可能なシグネチャが複数知られています。 ハニーポットであることをバレずに、攻撃者の活動を隅々まで観察するには、実際のファイルシステムを触らせる必要があります。しかしこんな事やってたら、本当に踏み台にされ犯罪加担してしまう可能性がありますし、(物理・VM)マシンコストも馬鹿になりません。 2. Linuxコンテナを使う Docker を使用することで、ホストコンピュータから安全に隔離し、ネットワーク・計算リソースを制限した上で攻撃者の活動を観察することができるのではないかと考えました。コンテナはVMに比べてリソース消費が格段に少なく、軽量です。 1攻撃者に1環境を与えることができるし、瞬時にクリーンな環境を提供できます。起動元のLinuxイメージは非破壊で、更新はレイヤーファイルシステムを採用しているため容量もそこまで食いません。ログやファイルの収集は、自作してもいいですが、Dockerに元々ある機能でも結構できます。 で、試作したものをCSS2016で発表しました。多くの問題を抱えているため実用的ではありませんが、Cowrieに比べてより活動的でいろいろ観察できて楽しかったです。 3. アーキテクチャ 3.1 要件 侵入しやすい環境 任意のID/PWでログイン可能 CPU・メモリ・ネットワークに制限を設ける DoS対策 コンテナに生存条件を設ける 制限時間 送受信トラフィック量 3.

GitHubの優秀な検索のせいでAWSなどのアクセスキーが流出している件

  • POSTS
⚠この記事はブログ移転前のアーカイブです GitHubって便利ですよね。この前AWSを使ったコードを書きました。 AWSの全データセンターから最も価格の低いスポットインスタンスを検索するスクリプト で、これ書く前、参考にGitHub漁ってたんですが、意外と「APIキーとシークレットをハードコードしてGitHubにアップロード」する人が未だにいるんだなあと思った。と同時に、「GitHubの検索が優秀すぎて簡単にAPIキーを探せる状況」であることに気付いた。 日本でもこんな事例 AWSが不正利用され300万円の請求が届いてから免除までの一部始終 が2015年から現在にかけてたまに聞きます。↑のは結構最近。 いや怖いですね。GitHubは数分前にインデックスされたソースコードもすぐに検索できますので下手するとアップロード後すぐに不正利用されてもおかしくありません。GitHubの検索が優秀すぎて逆に(悪い意味で)キー検索に便利な構造になってます。 もくじ 検索 GitHubのソースコード検索は登録者のみ AWSのAPIキー構造が検索のしやすさに拍車 共通のライブラリが検索のしやすさに拍車 もちろん多くのコードは対策済み 検索 画像とかリンクは載っけません。もちろん使えるかどうか確認など、キーを不正に使うことはしてはいけません。 GitHubのソースコード検索は登録者のみ ソースコードの詳細検索機能はGitHubアカウントにログインしている場合のみです。GitHubのトップページから検索することでグローバルな検索モードに入ることができます。 AWSのAPIキー構造が検索のしやすさに拍車 自分でAPIキー発行してても思ったのですが、少なくともEC2とS3はAWSのAPIキーは「必ずAKIAJから始まる」ようですね。シークレットはランダムなようですが、偏りがある気がします。 キーに固定値が入っていると格段に検索しやすくなるのはおわかりでしょう。なぜAWSが固定値から始めるのは謎です。何か理由があるのでしょうか。なければやめたほうがいいのではと思うのですが・・・? APIキーがハードコードされているソースが見つかった場合は、シークレットも必然的に近くに記述されています。当然です。APIを扱うオブジェクトを生成するのにキーもシークレットも必要ですし、開発者はpublicリポジトリにソースコードをホスティングしていることに無頓着な人間です。キーだけ記述されていてシークレットがどこにも無いパターンは少ないです。 共通のライブラリが検索のしやすさに拍車 AWSに限らずTwitterやFacebookなど、APIを扱うのに定番のライブラリがありますよね。そのライブラリで使用するキーやシークレットを記述する定数名が固定である場合が多いため、検索しやすくなります。 AWSのAPIを扱う定番ライブラリはPython3だとboto3です。boto3を環境変数を使わずにキーをハードコートする場合は、オブジェクト生成時に「aws_access_key_idとaws_secret_access_key」を指定します。これらを検索対象に含めることにより検索にヒットしやすくなります。 Twitterだと、TWITTER_CONSUMER_KEYや、TWITTER_CONSUMER_SECRETがよく使われます。TWITTER_ACCESS_TOKENや、TWITTER_ACCESS_TOKEN_SECRET なんかも検索ワードとして使えます。 もちろん多くのコードは対策済み 実際は流出しているコードよりも、もっと多くのコードがAPIキー流出をしないように対策しています。 例えば.envなどの環境設定ファイルにAPIキーを記述し、.gitignoreに.envを加えたりなどです。 他にも「TWITTER_CONSUMER_KEY=YOUR_COMSUMER_KEY」にしてダミーを入れておくようなコードも見かけます。 うっかりミスを防ぐためにもキーを記述したファイルは.gitignoreに加える対策が有効ではないかと思います。 boto3などでは環境変数にキーとシークレットを設定することで、コードに記述しなくても使用できるように配慮されています。 要はハードコードダメ・ゼッタイってやつですね。