カテゴリー: BLOCKCHAIN

復旧日誌8, [HDD/SSD/RAID] ブロックチェーン活用 統計スキャンについて その1

いつもお世話になっております。

実在証明を秒単位で刻むことが可能なブロックチェーンを活用する、
統計スキャンの実装となります。

まず、データのアセプト……受理については、
ピア情報の受け入れと似たようなロジックを実装いたしました。
なぜなら、何度も似たようなデータが来てしまうと、
必要性がないデータの多重処理で重くなるためです。

同じドライブについて何度も検査する過程自体は正常な処理です。
そのため、似た統計は再送信せず、
統計処理で偏ったものだけをアセプトすれば、
自然に、欲しい故障情報だけが集まってくる、そういった仕組みです。

次に、この統計データは専用のデータベースに保管されます。
つまり、ブロックチェーンはトランザクションだけに留めております。
これで、サイズの制約はありません。

そして、専用データベースの整合性については、マイナーが担当いたします。
ブロック承認ロジックに、この整合性処理を追加いたします。
新規ブロック受理の際に、
このデータベースのハッシュ値確認を、承認条件の一つにいたします。

ただし、これをstrictモードにするとハードフォークが必要となりますので、permissiveモードで処理する見込みです。
つまり、この承認を乗せたサーバ……、すなわち、v1.4(安定板)またはv4.0以降(最新版)のサーバに切り替わったノードだけでも、十分な整合性は取れると判断いたしました。

なにとぞよろしくお願いいたします。

chapter316, [SORA][BlockChain] Is LevelDB really fast to Blockchain?

We are currently checking performance of the blockchain that has migrated from LevelDB to SQLite.

In the case of LevelDB, in order to retrieve data using the sorted records arranged in a tree structure, it is necessary to deserialize unnecessary key data in order to apply conditions for exiting the search.

For example, if blockchain has 500,000 blocks, the key will be deserialized 500,000 times.
Then, since memcpy is called several times internally, it is a heavy process.
Furthermore, it will be strcmp in the comparison process. It’s heavy.

On the other hand, in the case of SQLite, the key can be specified in advance by the condition, so they only need to get the value.

復旧日誌6 [HDD/SSD/RAID] １０TBを超えたハードディスクの復旧について

いつもお世話になっております。
本日は、１０TBを超えたハードディスクの復旧について、です。

現在、ハードディスクの方は「データ保管用途」向けとなっております。
一方、システム起動用途としては、迷わずSSDで問題ございません。

そして、このハードディスクの容量が急拡大しております。
４TBから８TBで踏みとどまっていたものが、
急激に増加を開始し、１０TBは当たり前で、
そこから１６TBなども拝見する機会が多くなってきました。

この域に達しますと、
データの最小単位となるセクタで、すべてを辿る方法による復旧は、
もはや現実的ではございません。
ピンポイントでドライブの状態を監視しながら、
データを取り出す手法のみが有効です。
２０１６年より開発してきました「自動復旧」と、
現在開発中の「ブロックチェーン」を組み合わせて、
ドライブの状態管理用データの取り扱いまで自動化する、
新しい試みを、ようやくリリースできる見込みになりました。

いま、自動復旧を担うFromHDDtoSSDについて、
MinGWと呼ばれるコンパイラへの開発環境移行を試みております。
Linuxで広く使われるGCCのWindows版が、このMinGWになります。
ブロックチェーンの開発がMinGWだったゆえに、
今後の中心部を踏まえて、MinGWへの移行を決めました。
特に問題なくWindowsAPIおよびWindowsDDKが利用できるため、
そのままで問題ないとは思いますが、
なにゆえにドライブへのアクセスが絡みますので、
しっかり検証後、ブロックチェーンを取り込んで「リリース」となります。

なお、ブロックチェーンの「活用」がメインとなります。
検査に限り、ネットワーク手数料として僅かなSORAが必要となりますが、
それでも、大幅な時間短縮が実現される見通しです。

まず第一弾では、ドライブの弱い部分を探索できるようなロジックが組まれます。１０ＴＢ等の大容量をすべて検査するのは、時間がいくらあっても足りません。

そして、このようなドライブが沢山あると検査が面倒になって、そして、です……。

なお復旧系は、SQLiteに蓄積されたブロックチェーンを読み取って、
それらを手掛かりとするため、ネットワーク手数料は不要です。

もちろん、従来からある「完全スキャン」などは
ブロックチェーン非経由となりますので、今まで通りです。

そして、インストール不要版です。
パターンのダウンロードを必須としていましたが、今回、その全てを内蔵いたします。
それゆえに、ネットワーク非接続にて簡単にご利用いただける形になります。
※「ブロックチェーン非経由版」としては、これで完成です。

なにとぞよろしくお願いいたします。

chapter309, [SORA][FinexDriveChain] We have successfully migrated data from BerkeleyDB to SQLite.

We have successfully migrated data from BerkeleyDB to SQLite.

We can now say goodbye to the older version (Apr-2010) of BerkeleyDB.
And we will prepare the library with the latest version and
deploy SORA wallet on various platforms such as Android, iOS and so on.

db.cpp, CSqliteDB::PortToSqlite(DbIterator ite)
https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/db.cpp

chapter307, [SORA][FinexDriveChain] we was able to confirm the correct operation of the wallet with the latest version of SQLite!

We was able to confirm the correct operation of the wallet with the latest version of SQLite!
Now that we are going to test the robustness.

Because the Berkeley DB in use now has an older version (v4.8.30), we hope to use latest version … but … hahaha.

Therefore, we would like to do my best in this SQlite wallet verification as well!

db.h
https://github.com/FromHDDtoSSD/SorachanCoin-qt/blob/master/src/db.h