「Bitcoin-Powered Database」の版間の差分

提供: tezos-wiki
移動先: 案内、 検索
細 (1版 をインポートしました)
1行目: 1行目:
−
[https://booster.io/tipjar/0c9zmrc Bounty jar for this project].
+
[このプロジェクトのためのhttps://booster.io/tipjar/0c9zmrcバウンティジャー]。
  
−
As far I know, the Bitcoin blockchain is pretty much the only data structure that is both global and tamper-proof.
+
私が知る限り、Bitcoinブロックチェインは、グローバルと改ざんの両方を防ぐ唯一のデータ構造です。
  
−
* '''global''' - There is one global instance of the blockchain (up to forks ... which are then resolved).
+
* '' 'global' '' - ブロックチェーンのグローバルインスタンスが1つあります（フォークまでが解決されます）。
−
* '''tamper-proof''' - If a block enters the blockchain, after 6+ confirmations this block can't be feasible faked or altered.
+
* '' 'tamper-proof' '' - ブロックがブロックチェーンに入ると、6回以上の確認の後、このブロックは偽装されたり改ざんされたりすることはありません。
  
−
A Bitcoin-powered database would be an API over the blockchain, that would expose a subset of the usual [http://en.wikipedia.org/wiki/Crud CRUD] database operations. In fact, it would be an append-only data structure, because nothing can ever be really deleted from the blockchain - so only CREATE and READ operations will be implemented. Object Versioning will be used to emulate updates and deletions.
+
Bitcoinで動くデータベースは、通常の[http://en.wikipedia.org/wiki/Crud CRUD]データベース操作のサブセットを公開するブロックチェーン上のAPIになります。実際には、ブロックチェーンから実際には何も削除できないため、追加専用のデータ構造になるため、CREATE操作とREAD操作だけが実装されます。オブジェクトのバージョン管理は、更新と削除をエミュレートするために使用されます。
  
−
== Use Cases ==
+
==ユースケース==
  
−
=== Undeletedable, Auditable Asset ledger ===
+
===削除不能、監査可能な資産元帳===
−
On May 2012, [[Bitcoinica]] was hacked, and its ledger database was deleted. If its ledger were managed on a global, tamper-proof database, this would not have been possible.
+
2012年5月、[Bitcoinica]がハッキングされ、元帳データベースが削除されました。その元帳がグローバルな改ざん防止データベースで管理されていた場合、これは可能ではありませんでした。
  
−
Such a ledger can be constructed in a way where each balance is encrypted by a key known only to the site operator and the owner of the balance, in order to keep the account balance private. While a Bitcoin-Powered Database might not have adequet performance characteristics to perform as the backend of most websites, it can be used as a persistent data backup, that can be independently verified by a websites users.
+
このような元帳は、アカウントの残高を秘密に保つために、各天びんをサイト運営者と天秤の所有者のみが知っている鍵で暗号化する方法で構築することができます。 Bitcoin Powered Databaseは、ほとんどのWebサイトのバックエンドとして実行するのに適したパフォーマンス特性を持っていない可能性がありますが、永続的なデータバックアップとして使用することができます。
 +
==実装==
 +
通常のデータベースは、サーバとクライアントライブラリで構成されています。 この場合、「サーバー」はすべてマイナーノードであるため、クライアントライブラリのみが必要です。 すべての操作はBitcoinトランザクションとしてエンコードされます。
  
−
== Implementation ==
+
[[ブロックチェーンメッセージサービス]]を使用して、ブロックチェーン内のパラメータ '' 'メッセージ' ''をエンコードするプリミティブPUT（メッセージ）を使用します。
−
Regular databases are composed of a server and a client library. In this case, the "server" is all the miner nodes, so only a client library is needed. All operations are encoded as Bitcoin transactions.
 
  
−
We will use a primitive PUT(message) that encodes the parameter '''message''' in the blockchain using a [[Block chain message service]].
+
===作成（guid、バージョン、エンコーディング、データ、所有者_公開鍵、ハッシュアルゴリズム、署名）===
  
−
=== CREATE(guid, version, encoding, data, owner_pub_key, hash_algorithm, signature) ===
+
この操作で新しいレコードが作成されます。
  
−
This operation creates a new record.
+
* guid - クライアントが生成したこのオブジェクトを識別する一意のID。
 +
* version - オブジェクトのバージョン番号。
 +
* encoding - データのエンコーディングを識別するenum（例えば、jsonの場合は0、zipのjsonの場合は1、必要に応じて他のフォーマットを追加することができます）
 +
*データ - アプリケーション固有。データは***エンコーディング***パラメータに従ってデコードする必要があります。
 +
* hash_algorithm - データを検証するために使用する暗号ハッシュ関数を指定するenum（RSA + bcryptの場合は0）。
 +
* owner_pub_key - このオブジェクトの所有者を識別する公開鍵（RSAなど）
 +
* signature - 他のすべてのパラメータに対するハッシュ値。 （bcrypt（RSA_encrypt（private_key、（guid、バージョン、エンコーディング、データ、hash_algorithm、owner_pub_key）））。
  
−
* guid - a unique ID identifying this object, generated by the client.
+
CREATE操作が特定のGUIDで初めて使用されるとき、そのバージョンは0に等しくなければならず、任意のowner_pub_keyを提供することができます。このGUIDを持つ後続のCREATEオペレーションは、同じowner_pub_keyを持つ必要があり、1 + max（同じguidを持つオブジェクトの以前のバージョン）に等しいバージョンを持つ必要があります。
−
* version - an object version number.
 
−
* encoding - enum identifying the encoding of the data (e.g. 0 for json, 1 for zipped json, ... other formats can be added if needed)
 
−
* data - application specific. The data should be decoded according to the ***encoding*** parameter.
 
−
* hash_algorithm - An enum specifying which cryptographic hash function is used to verify data (0 for RSA+bcrypt, ...).
 
−
* owner_pub_key - A public key identifying the owner of this object (e.g. using RSA)
 
−
* signature - hash over all the other parameters - e.g. (bcrypt(RSA_encrypt(private_key, (guid, version, encoding, data, hash_algorithm, owner_pub_key))).
 
  
−
The first time a CREATE operation is used with a particular guid, its version should be equal to 0, and any owner_pub_key can be provided. Any subsequent CREATE op with this guid must have the same owner_pub_key, and must have a version equal to 1+max(previous versions of objects with the same guid).
+
無効なCREATEは無視されます（たとえば、不適切なバージョンまたは間違った署名のあるCREATEなど）。
  
−
Any invalid CREATEs are ignored (e.g. CREATE with incorrect version or wrong signature).
+
CREATE操作では、Bitcoinがネットワークによって「実行」されるのにかかるコストがかかります。正確な量は、PUT操作の実装に依存します（CREATEの生の実装は、パラメータの連結）。
  
−
It should be mentioned that CREATE operations cost some amount of Bitcoin to be "performed" by the network - the exact amount depends on the implementation of the PUT operation (The raw implementation of CREATE is just to PUT a message with the concatenation of its parameters).
+
=== READ（guid）===
  
−
=== READ(guid) ===
+
この操作は、このGUIDを持つオブジェクトのすべての有効なバージョンの配列を返します（オブジェクトが存在しない場合は空の配列）。ブロックチェーンをたどってこのguidで最初のメッセージを探し、owner_pub_keyを格納し、そこから前方に移動して、有効なバージョンを識別し、無効なものを破棄することで、これは単純に実装されます。この素朴な実装は非常にコストがかかりますが（O（ブロックチェーンサイズ））、キャッシュできます。
  
−
This operation returns an array of all the valid version of an object with this guid (or an empty array if the object does not exist). It is naively implemented by traversing the blockchain and looking for the first message with this guid, storing the owner_pub_key, and moving forward from there, identifying the valid versions and discarding invalid ones. This naive implementation is very costly (O(blockchain size)), but can be cached.
+
==元帳のサンプル実装==
 +
富士山などのトレーディングサイト。 Gox、GLBSE、Bitcoinicaは、各ユーザーと資産クラス（BTC、USD、有価証券）ごとに、特定の瞬間に自分が所有する資産の量を記録するシステムである元帳を使用します。このようなサイトでBPD上で監査可能な公的元帳を実装する簡単な方法があります。
  
−
== Sample implementation of a ledger ==
+
*すべてのユーザーに対して、一意の暗号化キーとGUIDの両方を作成します。これらは登録時にすぐにユーザーに送信され、Webサイトの通常のデータベースにも保存されます。
−
Trading websites such as Mt. Gox, GLBSE and Bitcoinica use a ledger - a system that records, for each user and asset class (BTC, USD, securities), the quantity of assets he owns at any given moment in time. Here is a simple way for such sites to implement an auditable public ledger over BPD.
+
*サイト上のトランザクションごとに、ユーザーのすべての資産を含むステートメントが何らかの形式でエンコードされ、ユーザーのGUIDおよび暗号化キーを使用して暗号化された形式でBPDに書き込まれます。
 +
*ユーザがwebiste上の資産を確認したいときはいつでも、彼は彼のguidでREAD操作を実行し、その後彼の解読鍵を使って彼の残高を解読する。その後、彼は現在のアカウントと以前のアカウントを検証することができます。
  
−
* For every user, we create both a unique encryption key and a guid. These are sent to the user immediately upon registration, and are also stored in the website's normal database.
+
BPD内のすべてのデータは暗号化されているため、このシステムではWebサイトのセキュリティは低下しません（ユーザーのコンピュータはトロイの木馬がないものとみなされます。これが問題であれば、ユーザーは自分のコピーを受け取ることはできません）暗号化キー...これは、少なくともサイトの所有者が元帳を認証する確実な方法を持っているため、BPDを使用しない方が好ましいです。削除や改ざんはできません。guidsと暗号化キーは保護され、バックアップされます）。
−
* For every transaction on the site, a statement comprising all of the user's assets is encoded in some format, and then written to the BPD in encrypted form, using the user's guid and encryption key.
 
−
* At any point when the user wishes to verify his assets on the webiste, he performs a READ operation with his guid, and then decrypts his balances using his decryption key. He can then validate his current and previous account.
 
−
 
 
−
Note, this system does not reduce the security of the website, because all data in the BPD is encrypted (we assume the user's computer is trojan-free - if this is an issue, the user may opt-out of receiving a copy of his encryption key ... this is still preferable to not using a BPD, because at least the site's owner would have a sure way of authenticating the ledger, that can't be deleted or tampered with ... with the assumption that the guids and encryption keys are secure and backed up).
 

2018年4月12日 (木) 15:36時点における版

[このプロジェクトのためのhttps://booster.io/tipjar/0c9zmrcバウンティジャー]。

私が知る限り、Bitcoinブロックチェインは、グローバルと改ざんの両方を防ぐ唯一のデータ構造です。

  • 'global' - ブロックチェーンのグローバルインスタンスが1つあります（フォークまでが解決されます）。
  • 'tamper-proof' - ブロックがブロックチェーンに入ると、6回以上の確認の後、このブロックは偽装されたり改ざんされたりすることはありません。

Bitcoinで動くデータベースは、通常のCRUDデータベース操作のサブセットを公開するブロックチェーン上のAPIになります。実際には、ブロックチェーンから実際には何も削除できないため、追加専用のデータ構造になるため、CREATE操作とREAD操作だけが実装されます。オブジェクトのバージョン管理は、更新と削除をエミュレートするために使用されます。

ユースケース

削除不能、監査可能な資産元帳

2012年5月、[Bitcoinica]がハッキングされ、元帳データベースが削除されました。その元帳がグローバルな改ざん防止データベースで管理されていた場合、これは可能ではありませんでした。

このような元帳は、アカウントの残高を秘密に保つために、各天びんをサイト運営者と天秤の所有者のみが知っている鍵で暗号化する方法で構築することができます。 Bitcoin Powered Databaseは、ほとんどのWebサイトのバックエンドとして実行するのに適したパフォーマンス特性を持っていない可能性がありますが、永続的なデータバックアップとして使用することができます。

実装

通常のデータベースは、サーバとクライアントライブラリで構成されています。 この場合、「サーバー」はすべてマイナーノードであるため、クライアントライブラリのみが必要です。 すべての操作はBitcoinトランザクションとしてエンコードされます。

ブロックチェーンメッセージサービスを使用して、ブロックチェーン内のパラメータ 'メッセージ' をエンコードするプリミティブPUT（メッセージ）を使用します。

作成（guid、バージョン、エンコーディング、データ、所有者_公開鍵、ハッシュアルゴリズム、署名）

この操作で新しいレコードが作成されます。

  • guid - クライアントが生成したこのオブジェクトを識別する一意のID。
  • version - オブジェクトのバージョン番号。
  • encoding - データのエンコーディングを識別するenum（例えば、jsonの場合は0、zipのjsonの場合は1、必要に応じて他のフォーマットを追加することができます）
  • データ - アプリケーション固有。データは***エンコーディング***パラメータに従ってデコードする必要があります。
  • hash_algorithm - データを検証するために使用する暗号ハッシュ関数を指定するenum（RSA + bcryptの場合は0）。
  • owner_pub_key - このオブジェクトの所有者を識別する公開鍵（RSAなど）
  • signature - 他のすべてのパラメータに対するハッシュ値。 （bcrypt（RSA_encrypt（private_key、（guid、バージョン、エンコーディング、データ、hash_algorithm、owner_pub_key）））。

CREATE操作が特定のGUIDで初めて使用されるとき、そのバージョンは0に等しくなければならず、任意のowner_pub_keyを提供することができます。このGUIDを持つ後続のCREATEオペレーションは、同じowner_pub_keyを持つ必要があり、1 + max（同じguidを持つオブジェクトの以前のバージョン）に等しいバージョンを持つ必要があります。

無効なCREATEは無視されます（たとえば、不適切なバージョンまたは間違った署名のあるCREATEなど）。

CREATE操作では、Bitcoinがネットワークによって「実行」されるのにかかるコストがかかります。正確な量は、PUT操作の実装に依存します（CREATEの生の実装は、パラメータの連結）。

READ（guid）

この操作は、このGUIDを持つオブジェクトのすべての有効なバージョンの配列を返します（オブジェクトが存在しない場合は空の配列）。ブロックチェーンをたどってこのguidで最初のメッセージを探し、owner_pub_keyを格納し、そこから前方に移動して、有効なバージョンを識別し、無効なものを破棄することで、これは単純に実装されます。この素朴な実装は非常にコストがかかりますが（O（ブロックチェーンサイズ））、キャッシュできます。

元帳のサンプル実装

富士山などのトレーディングサイト。 Gox、GLBSE、Bitcoinicaは、各ユーザーと資産クラス（BTC、USD、有価証券）ごとに、特定の瞬間に自分が所有する資産の量を記録するシステムである元帳を使用します。このようなサイトでBPD上で監査可能な公的元帳を実装する簡単な方法があります。

  • すべてのユーザーに対して、一意の暗号化キーとGUIDの両方を作成します。これらは登録時にすぐにユーザーに送信され、Webサイトの通常のデータベースにも保存されます。
  • サイト上のトランザクションごとに、ユーザーのすべての資産を含むステートメントが何らかの形式でエンコードされ、ユーザーのGUIDおよび暗号化キーを使用して暗号化された形式でBPDに書き込まれます。
  • ユーザがwebiste上の資産を確認したいときはいつでも、彼は彼のguidでREAD操作を実行し、その後彼の解読鍵を使って彼の残高を解読する。その後、彼は現在のアカウントと以前のアカウントを検証することができます。

BPD内のすべてのデータは暗号化されているため、このシステムではWebサイトのセキュリティは低下しません（ユーザーのコンピュータはトロイの木馬がないものとみなされます。これが問題であれば、ユーザーは自分のコピーを受け取ることはできません）暗号化キー...これは、少なくともサイトの所有者が元帳を認証する確実な方法を持っているため、BPDを使用しない方が好ましいです。削除や改ざんはできません。guidsと暗号化キーは保護され、バックアップされます）。

「http://tezos-wiki.jp/wiki/index.php?title=Bitcoin-Powered_Database&oldid=17414」から取得