Avalancheについて|ブロックチェーン3.0

Avalancheについて|ブロックチェーン3.0
Avalancheは、追加のプロトコル層を作成したり、何かの機能を得るために何かを犠牲にするのではなく、レイヤ1にスケーラビリティ、迅速なファイナリティ、優れたパフォーマンス、分散化を導入します。


CoinPicks Labでは、BitcoinやEthereum、時事情報に焦点を絞り毎週金曜日レポートを配信しています。

レポートを希望する

Avalancheについて|ブロックチェーン3.0

コーネル大学のEminGünSirer教授とAVA Labsの共同創設者である、コーネル大学のPh.DのKevin Sekniqi氏とTed Yin氏が率いる「AVA Labs」チームは「Alpine Snowstorm」のコンセプトを明らかにしました。

これは、Snow‐Avalancheと呼ばれる新しい準安定のコンセンサスプロトコルファミリに基づく次世代ブロックチェーンプラットフォームのためのプライベートテストネットとして構築されました。

過去2~3年の間に複数のプロジェクトが出現したにもかかわらず、ブロックチェーンの分野ではまだ大きなイノベーションは起きていません。これは、未だ解決されない深刻な技術的ボトルネックによって妨げられているといえます。

これまでのブロックチェーンの進化

■ Blockchain 1.0:デジタル保存及び価値の移転

  • Bitcoin:ピアツーピア電子現金システム。
  • Litecoin:ピアツーピアの暗号通貨。
  • Dogecoin:ミームコイン。

■ ブロックチェーン2.0:プラットフォームと機能性/フィーチャ指向

  • Ethereum:スマートコントラクトプラットフォーム。
  • Monero:プライバシー指向の暗号通貨。
  • Stellar:資産間の価値の移転。
  • Dash:マスターノードを利用して追加の機能とガバナンスを実現する決済用の暗号通貨。

上記ブロックチェーン1.0から派生した多様なプロジェクトが存在しています。それらの課題の解決策としてブロックチェーン2.0では、拡張性、パフォーマンス、機能性を向上させるさまざまなプロジェクトがローンチされました。その中には、レイヤ1のみではなくサイドチェーンとしてのライトニングネットワークとステートチャネルのような追加レイヤも組み込まれています。その実装には現状としてトレードオフが伴い、多くの場合分散性が犠牲にされています。

Avalanche Consensus

古典的なコンセンサスとナカモトコンセンサスから学んだ教訓を伴うプロトコルとゴシップネットワークに触発された準安定コンセンサスプロトコルとして「Avalanche Consensus」が提案されています。これは、過去の教訓の長所を組み合わせることでレイヤ1の既知の問題を根本的に改善することを目的としています。

  • 迅速なファイナリティと低レイテンシ:世界中でファイナリティを実現するには、約1~2秒必要です。これは決済処理と確認にかかる時間です。
  • スループットの向上:1,000~10,000トランザクション/秒。NYC Blockchain WeekにてAWSの1,000ノードを超える、6,500TPSをベンチマークしました。
  • 堅牢:確実なコンセンサスを得るために、ネットワークは参加者のIDについて合意する必要はありません。
  • 静止プロトコル:安全性を確保するためにエネルギーや特定のハードウェアリソースを必要としない為、環境に優しいプロトコルです。
  • 高スケーラビリティ:このプロトコルは軽量であるため、拡張性と低レイテンシが認められます。
  • 平等主義のエコシステム:Avalancheプロトコルは平等主義的なエコシステムを構築します。つまり、ネットワーク内のすべてのノードの重みは同じです。マイニング従事者が存在しないため、「プール」へのハッシュパワーの集中化は発生しません。
  • ビザンチン耐性:ビザンチン参加者の大半は、安全性に影響を与えずに許容されます。例えば、Avalancheの特定の構成では、ノードの最大50%をビザンチンにすることができます。つまり、ネットワークをだましてネットワーク全体の不均衡を維持しようとするノード構成になる可能性があります。ただし、2つのノードが同時に2つの異なる色を決定するような方法でこれを行うことはできません。
  • ブロックチェーン3.0:Avalanche

Avalancheは、追加のプロトコル層を作成したり、何かの機能を得るために何かを犠牲にするのではなく、レイヤ1にスケーラビリティ、迅速なファイナリティ、優れたパフォーマンス、分散化を導入します。さらに、このチームは、ブロックチェーン1.0及び2.0から得られた教訓を活用して、現在のプロジェクトのボトルネックとなっている問題を解決に導きます。

「デジタルキャッシュと決済処理」を改善

AVA(Avalanche)がVISAのTPSのほぼ4倍をベンチマークしたという事実以外に、伝えるべきことは多くありません。

  • Bitcoin:7トランザクション/秒
  • Ethereum:15トランザクション/秒
  • Ripple:1,500トランザクション/秒
  • VISA:1,700トランザクション/秒
  • PayPal:193トランザクション/秒
  • AVA:6,500トランザクション/秒

DAppsプラットフォームを改善

DAppsには、Web 2.0 Appsよりも様々な利点がありますが、導入にはコストがかかります。ユーザーがテクノロジーの恩恵を受け、プレミアム機能だけにお金を払うことに慣れているフリーミアムデジタルの世界では、バーチャルな子猫を繁殖させたり、暗号化されたメッセージを送信するために3ドル(約325円)という手数料は高いハードルであるといえます。

イノベーションの初期段階において、このような高コストは目新しいものではありません。携帯電話、コンピュータやモバイルOS、インターネットなどの革新的な製品の歴史において、使用の複雑さや高コストのために、当初は大多数のユーザーがアクセスできませんでした。しかし、テクノロジーが向上し、コストが下がるにつれて採用が増えていったのです。Geoffrey Moore氏は、1991年に出版した著書の中で、ハイテクイノベーションが飛躍的に普及する鍵は、「キャズム」を克服することであると論じています。彼はこの隔たりを、アーリーアダプターとアーリーマジョリティの間に横たわる大きなギャップであると述べています。 参照: (Moore, 1991; Nesmith, 2018)

導入コストの他に、トランザクションがブロックにインプットされるまでには長い時間がかかるため、DAppのパフォーマンスは非常に制限されます。

Ethereumを使用する:
現在のパラメータでは、各メッセージの送信に必要なコストは0.125ドル(約13.56円)で、4~29秒経過後にメッセージが受信されます(平均13秒)。ネットワークの負荷が高くなると、ユーザーはさらに長い時間必要になります。

Avalancheを使用する:
暗号化されたメッセージの送信時間は1~2秒です。トランザクションコストは以下の2つの理由によって低くなります。

  1. コスト値を管理することができる柔軟性。
  2. 余裕のあるネットワーク容量(過負荷になりにくい)。

要するに、Avalancheはクラウドオラクルとしての役割があり、ハードフォークなしにパラメータへの投票が可能であり、動的に調整することができます。これは、ネットワーク参加者がいつでもプラットフォームを最善の状態にすることができ、特定の取引タイプのコストを変更できることを意味します。

「トークン化」を改善

AVAはプラットフォームのプラットフォームであるといえます。あらゆる種類のデジタル資産を誰でも発行することができます。AVAは複数のスクリプト言語と複数のVM(バーチャルマシン)をサポートします。つまり、様々な機能を持つさまざまなノードをサポートすることで、プロセスにおけるデジタル資産、機能、機能の新たなスペクトルを開くことができます。

「分散化と不変性」を改善

Avalancheは極端な分散化を導入しています。これは、軽量で実装/理解が容易で、特殊なハードウェアを必要としないため、数千から数百万のネットワーク参加者が利用できるようにすることで、エコシステムの非常に高い不変性を実現します。

「ビジネス向けブロックチェーン」を改善

  • プライベート・スマートコントラクト
  • レイテンシーとブロックのファイナリティ
  • プライベートサイドチェーン
  • サイドチェーンでの加速の可能性

「ガバナンス」を改善

AVAは投票を通じた経済的ガバナンスを導入しており、これはプロトコル自体の中核機能です。コンセンサスはサブサンプリングされた投票によって得られ、同様の投票メカニズムを完全に分散化されたガバナンス使用することができます。これにより、重要なパラメータの調整など、プロトコルレベルでの変更が可能になります。

例えば…

  • 特定のTXタイプのコストが高すぎる為、AVAネットワークは、特定のTXタイプの実行コストを下げるように投票します。
  • インフレ率が高くなってきているので、採掘率を下げるための投票が開始されます。

基本的にクラウドオラクルであることによって、AVAは台帳の不変性を危険にさらすことなく非常に柔軟であることが分かります。

「ユーザーエクスペリアンス」を改善

この段階ではUXに関する完全な詳細が欠けています。それにもかかわらず、AVA Labsチームは、ユーザーエクスペリエンスの問題と障害をを認識しています。

UI/UXの進化は、ニューヨークのTokenSummit2019にてSirer教授の議題にもなりました。

Reference
https://hackernoon.com/avalanche-ava-blockchain-3-0-a-novel-metastable-consensus-protocol-28cdc4ee8984

 

CoinPicks Lab

レポートを希望する

位置情報を参照できる標準プロトコル|FOAM

位置情報を参照できる標準プロトコル|FOAM
FOAMというプロジェクトは、分散性、プライバシー保護を維持しながら検閲されないGPSの代わりとなるような位置情報のインフラを提供することを目的としています。


CoinPicka Labでは、BitcoinやEthereum、時事情報に焦点を絞り毎週金曜日レポートを配信しています。

レポートを希望する

位置情報を参照できる標準プロトコル|FOAM

FOAMというプロジェクトは、分散性、プライバシー保護を維持しながら検閲されないGPSの代わりとなるような位置情報のインフラを提供することを目的としています。

あらゆるサービスに位置情報が活用される中で、Googleなどの主体があるものに管理されていることに課題を定義しています。また、1つの主体に位置情報の完備を任せるには、荷が重く国連の調査情報では、世界の70%の土地の情報は集まっていないとのことです。

FOAMの競合として、OpenStreetMap OSM)というオープンソース位置情報サービスもありますが、情報の正しさをユーザー同士で評価する仕組みがありません。また、GPSでは屋内の位置情報の検証は難しく、バッテリー消費が激しいといった課題もあります。

そこでFOAMでは、CSCCrypto Spatial Coordinate)といった新しい位置情報のコード化の規格を作っています。CSCは、ジオハッシュ+Ethereumのコントラクトアドレスで構成されています。このような形で位置情報がどんどん追加されていき、スマートコントラクトを通して位置情報の参照が可能になります。

この場所の追加はTCRToken Curated Registry)というアーキテクチャを採用しています。これはトークンのインセンティブ設計を活用して情報のホワイトリスト、ブラックリストを作成するというものです。これによってトークン保有者(50FOAM)で位置情報を検証しながら追加していくことができるということです。

下記URLから実際にアプリケーションに登録された位置情報の確認ができます。

[blogcard url=”https://map.foam.space/#/at/?lng=139.7528866&lat=35.6907341&zoom=12.33″%5D

Reference
https://foam.space/

 

CoinPicks Lab

レポートを希望する

ブロックチェーン・シャーディング PART2

ブロックチェーン・シャーディングのPART2を和訳しました。全文の中から日本人でも理解がしやすいように筆者独自の表現に変換している部分が多々ありますのでご了承ください。こちらの記事を読んでいただくことで、シャーディングの課題であるデータの有効性と可用性について学ぶことができます。


前回のブロックチェーン・シャーディング PART1を読まれていない方は、先にこちらを読んで頂くとことで、より理解を深めて頂けます。

[blogcard url=”https://coinpicks1.wordpress.com/blockchain-sharding1/”%5D

また、NEAR Protocolの日本版テレグラムはこちらから参加頂けます。

[blogcard url=”https://t.me/joinchat/GLZiexXRiYpYEwwNH3znPQ”%5D

 

シャーディング・ブロックチェーンの課題

PART1では、Sharding(以下 シャーディング)に関する主要な概念について説明しました。 この記事では、2種類の課題であるデータの可用性とデータの有効性を含む、より高度な側面からシャーディングについて説明します。

基本的な考え方として、ネットワークに参加している個人は、検証のためにシャードをまたいでブロックの履歴全体をダウンロードすることはできません。この性質によりシャーディングには大きな課題があります。それは、シャード同士の相互作用(コミュニケーション)によって生成されているブロックが正しい結果なのか否かを確信することができないというものです。

この問題を解決するためにどのような提案がされているのかについて説明していきたいと思います。

 

悪意のあるフォークの作成と無効なブロック生成

例えば、ネットワーク全体で数千人のバリデータが存在しており、そのうち悪意のある又はオフラインになっているバリデータが20%以下と仮定します。次に、200個のバリデータをサンプリングした場合、1/3を超える数が悪意あるバリデータである可能性は限りなくゼロとみなすことができます。

シャード内のバリデータは、そのシャードを正規チェーンとしてブロックを生成します。ブロックは同じバリデーションによって、正規チェーンの先頭に構築されます。生成されたブロックは帰納法によりチェーン全体を有効な状態として考えることができます。

しかし、正常なバリデータが機能していないと仮定した場合、この単純な解決策通りにはいきません。

プロトコルのセキュリティーとして、シャーディングブロックチェーンはそうでないブロックチェーンと比較して、はるかに耐性が低く安価な攻撃が可能です。したがって、プロトコルのセキュリティはシャードの数とともに直線的に減少します。適応型敵対者が存在する場合、悪意のあるフォークの作成と無効なブロック生成が実行できてしまいます。

悪意のあるフォークは、一般的にシャードチェーンよりもかなり高いセキュリティを持つように設計されているビーコンチェーンへのクロスリンクによって対処できます。しかし、無効なブロック生成への対応は大きな課題となっています。

 

データの有効性

1つ目の課題はデータの有効性です。

次の図で、シャード#1が破損し、悪意のある参加者が無効なブロックBを作成したとします。このブロックBでは、アリスのアカウントで1000トークンがマイニングされたとします。次に、悪意のある参加者は、無効なブロックBを難読化して、有効なブロックCを(Cのトランザクションが正しく適用されるという意味で)Bの上に生成し、Shard2でボブのアカウントへのクロスシャードトランザクションを開始します。これによって、不適切に作成されたブロックは完全に有効なシャード#2のブロックチェーンに存在することになります。

この問題に対する解決策としていくつか方法があります。

1.Shard2のバリデータによってトランザクションが開始されたブロックの検証をします。しかし、上図のように完全に有効化されたブロックCには対応できません。

2.シャード#2のバリデータがトランザクションが開始されたブロック以前のブロックを検証します。しかし、シャードによって検証されたN個のブロックに対して、悪意のあるバリデータが生成した無効ブロック上にN + 1個の有効ブロックを作成することができます。

この問題を解決するための有望なアイデアは、他の各シャードに接続されたUndirectedグラフにシャードを配置し、隣接するシャード間でクロスシャードトランザクションの許可をすることです。隣接していないシャード同士のコミュニケーションが必要な場合、そのようなトランザクションは複数のシャードを介して経路が指定されます。この設計では、各シャード内のバリデータは、シャード内のすべてのブロックと、隣接するすべてのシャード内のブロックを検証することが期待されています。各ノードは4つの隣接するノードを持ち、クロスシャード通信に2つ以上のホップを必要とする以下の図を考えてみてください。

シャード#2は、自身のブロックチェーンだけでなく、シャード#1を含むすべての隣接するブロックチェーンも検証しています。 そのため、シャード#1の悪意のある参加者が無効なブロックBを作成後、その上にブロックCを構築してクロスシャードトランザクションを開始した場合でも、シャード#2はシャード#1を検証済みなのでクロスシャードトランザクションは成功しません。Shard1の履歴から無効なブロックBを識別することができます。

 

しかし、複数のシャードに対する攻撃には課題が残ります。下図のようにシャード#1とシャード#2の両方に対する攻撃を実行した場合、無効なブロックBの作成によるクロスシャードトランザクションは、シャード#3で正常に実行されてしまいます。

シャード#3は隣接するシャード#2内のすべてのブロックを検証しますが、シャード#1内のブロックは検証しません。よって悪意のあるブロックを検出する方法がないということになります。

データの有効性を解決するには、FishermenとCryptographicによる2つの証明方法があります。

 

Fisherman

Fishermenとして、ブロックヘッダーが何らかの目的でチェーン間のコミュニケーションをするときには、正直なバリデータがブロックが無効であることを証明する期間が存在します。構造上、ブロックが無効であるという証明を可能にするために、受信側ノードの通信オーバーヘッドは、フルブロックを受信するときよりもはるかに小さくなります。

このアプローチでは、シャード内に少なくとも1つの正直なバリデータが存在している限りシステムは安全と言えます。

これは、現在提案されているプロトコルの中で主流のアプローチです。ただし、この方法には2つの大きな欠点があります。

1.正直なバリデータがブロックの生成を認識すると、ダウンロードと検証がはじまり無効なブロックを発見した場合に、そのブロックを無効にするための長いチャレンジ期間が必要です。長いチャレンジ期間を導入することでクロスシャードトランザクションを遅らせることができます。

2.チャレンジ期間の存在は、悪意のあるノードに新たな攻撃経路(無意味なチャレンジ)を作ることになります。この問題に対する解決策は、チャレンジを実行する際にトークンのデポジットを義務付けておくことです(悪意がなければチャレンジ後に返還されます)。しかし、攻撃者からみてデポジットしたトークンと攻撃による利益を天秤にかけて、攻撃による利益が上回る可能性もあるため、この方法がベストプラクティスとは言えません。このような攻撃は「Griefing Attacks」と呼ばれています。

Fishermanの2つの問題に対する解決策があるわけではありませんが、Fishermanを使用することで、無効ブロックの確定に対する耐性がある点で優れていると言えます。

 

Succinct Non-interactive Arguments of Knowledge

複数のシャードに対する攻撃の解決策は、ある種のCryptographic Constructions(トランザクションの集合からのブロックの計算など)が正しく実行されたことを証明できるようにすることです。そのような構成は存在します。 zk-SNARKszk-STARKsなどのプライベートペイメントのために積極的に使用されています。このようなプリミティブな問題は計算に時間がかかることで有名です。例えば、CodaProtocolはチェーンの全てのブロックが有効であることを保証するためにzk-SNARKsを使用していますが、あるインタビューで、証明のために1トランザクションあたり30秒かかる可能性があると述べています(現在のTPS(処理速度)は向上している可能性があります)。

興味深いことに、ブロックが構築された計算の妥当性を証明するだけでなく、証明自体の妥当性も証明するので、証明自体は信頼できる当事者によって計算される必要はありません。したがって、そのような証明の計算は、少ない参加者の間で分割することができます。また、zk-SNARKsを計算する参加者がシステムの分散化を減らすことなく特別なハードウェア上で実行することも可能になります。

パフォーマンス以外でのzk-SNARKsの課題は、次のとおりです。

  • 研究とテストの回数が少ない。
  • すべての関係者が中間値を共謀して保持している場合は、偽の証明を作成できる。
  • システム設計が複雑。
  • スマートコントラクト言語を使用したプロトコルでは、チェーンの有効性を証明するためにSNARKsを使用することはできない。

多くのプロトコルがzk-SNARKsの導入を検討していますが、CodaProtocol以外に実用化されたものが確認できていません。

 

データの可用性

2つ目の課題はデータの可用性です。

通常、ノードは2つのグループに分けられます。フルノード(すべてのフルブロックをダウンロードしてすべてのトランザクションを検証するノード)とライトノード(ブロックヘッダーのみをダウンロードし、署名の一部や興味のある取引にはMerkleプルーフを使用する)です。

フルノードは有効または無効のブロックを作成して、そのハッシュをライトノードに送信することができますが、ブロックの完全な内容を開示することはできません。

上図には3つのブロックがあります。ブロックBのバリデータは、前のバリデータからブロックAを受け取り後に計算がはじまり、あなたが保有している資産をステートのマークルツリー証明付きでブロックBのヘッダに送ります。

しかし、バリデータはブロックBの内容を誰にも配布しません。そのため、ブロックCのバリデータは正確なブロックを取得できず、ブロックAの情報のみを受け取りブロックCを構築することを余儀なくされ2重払いが成功します。

同じシナリオをシャードに適用すると、通常、フルノードとライトノードの役割がシャードごとに適用されます。各シャード内のバリデータは、シャード内のすべてのブロックとトランザクションを検証します。シャードチェーンはビーコンチェーンに記述され、ヘッダーのみをダウンロードします。したがって、シャード内のバリデータはそのシャードの事実上フルノードであり、ビーコンチェーンを含むシステム内の他の参加者はライトノードとして機能します。

上で議論したFishermanのアプローチを成功させるためには、正直なバリデータがビーコンチェーンにクロスリンクしているブロックをダウンロードできる必要があります。しかし、悪意のあるバリデータが無効なブロックのヘッダをクロスリンクしたり(またはクロスシャードトランザクションを開始するためにそれを使用した場合)、そのブロックを配布しなかった場合、正直なバリデータはチャレンジを作成する手段がありません。

この問題に対処するために、互いに補完する2つのアプローチを取り上げます。

 

Proof of Custody

もっとも早急に解決されるべき問題は、発行されたブロックが利用可能か否かの判別です。提案されているアイデアの1つは、シャード間で頻繁にローテーションするいわゆる公証人を持つことです。バリデータとは異なり、シャードのステート全体をダウンロードする必要がないため、より頻繁にローテーションすることができます。

このアプローチの問題点は、公証人がブロックをダウンロードできたかどうかを後で証明することが不可能であるということです。そのため、公証人はブロックのダウンロードについて虚偽の発言が可能になります。これに対する1つの解決策は、公証人が何らかの証拠を提供したり、ブロックがダウンロードされたことを証明するために、ある程度の量のトークンをステークすることです。そのような解決策の1つはこちらで議論されています。

[blogcard url=”https://ethresear.ch/t/1-bit-aggregation-friendly-custody-bonds/2236″%5D

 

Erasure Codes

特定のライトノードがブロックのハッシュを受信したときに、そのブロックが使用可能であるというノードの信頼性を高めるために、ブロックのいくつかのランダムな部分をダウンロードしようと試みることができます。ライトノードがブロック全体をまとめてダウンロードしない限り、悪意のあるブロック作成者は、どのライトノードによってもダウンロードされなかったブロックの部分を差し控えることを選択できるため、依然として無効なブロックを作成できます。

1つの解決策は、ブロック全体を回復できるようにするために消去コードと呼ばれる構造を使用することです。

 

長期的なデータ可用性と結論

上記のすべてのアプローチは、ブロックが発行されたことを証明するものであり、ノードがオフラインになる、ノードが履歴データを意図的に消去するなど、さまざまな理由でブロックが使用できなくなる可能性があります。

言及する価値のあるホワイトペーパーはPolyshardです。Polyshardは、いくつかのシャードがデータを完全に失ってもブロックをシャード間で使用できるようにするために消去コードを使用しますしかし、Polyshardのアプローチは、他のすべてのシャードからブロックをダウンロードする必要があります。

幸いなことに、長期的な可用性はそれほど差し迫った問題ではありません。システムの参加者がすべてのシャードのすべてのチェーンを検証できるとは予想されないため、シャードプロトコルのセキュリティは一部のシャードに対してシステムは安全であるように設計することが必要です。

データの有効性とデータの可用性には、安全なプロトコルを設計する上で課題が残っています。私達はこれらの問題を積極的に研究しています。アップデートをお楽しみに!!

 

原文

 

Join Lab Now

ブロックチェーン・シャーディング PART1

ブロックチェーン・シャーディングの入門書ともいえる記事を和訳しました。全文の中から日本人でも理解がしやすいように筆者独自の表現に変換している部分が多々ありますのでご了承ください。こちらの記事を読んでいただくことで、シャーディングの基礎について学ぶことができます。


日本で初めてのNEAR ProtocolのミートアップがHashhubにて開催されます。情報の少ないNEARの最新情報を「日本語」で聞くチャンスです。席に限りがございますのでお早めにご参加ください。

[blogcard url=”https://hashhub.connpass.com/event/122030/”%5D

前回のThe Beginner’s Guide to the NEAR Blockchain – NEAR Protocol 入門書編 – を読まれていない方は、先にこちらを読んで頂くとことで、より理解を深めて頂けます。

[blogcard url=”https://coinpicks1.wordpress.com/near-protocol/”%5D

また、NEAR Protocolの日本版テレグラムはこちらから参加頂けます。

[blogcard url=”https://t.me/joinchat/GLZiexXRiYpYEwwNH3znPQ”%5D

 

Blockchain・Sharding

今回の記事では、ブロックチェーン・Sharding(以下 シャーディング(*1))が直面している課題と構築方法について説明したいと思います。

*1:シャーディングという単語は、破片を意味する英単語シャード(shard)に由来しています。データベース分野では古くから使用されている単語で、データを複数のデータベースに分散配置して、データベースの負荷を分散することを意味しています。

記事執筆時点でのEthereumの処理能力は、メインチェーン上で1秒間に約20トランザクション未満であることはよく知られています。処理能力の制限とネットワークの人気が相まって、ガス価格の高騰とおよび承認時間の遅延(低スループット)をもたらしています。

この低スループットの原因は何でしょうか?

その原因は、ネットワーク内のすべてのノードがすべてのトランザクションを処理しているからです。

2つの解決策が提案されています。

  • すべての演算処理を少数の強力なノードセットに委任
  • ネットワーク内の各ノード間で分割して演算処理をする

前者を採用しているのはThunderです。単一のノードですべてのトランザクションを処理し、1200 tx /秒という(Ethereumと比較して約100倍)スループットを実現しています。より多くのトランザクションを処理するためにコンセンサスとブロックチェーン構造でさまざまな改善案がありますが、その処理能力は1つのノードの処理速度に制限されています。

トランザクションの処理がすべての参加ノード間で分割される後者のアプローチは、シャーディングと呼ばれています。これが、Ethereum Foundationが現在計画しているEthereumをアップグレードする方法です。

*2:執筆時点でシャーディングの完全な仕様は公開されていません。

そして、Near Protocolもシャーディングを構築しています。

NEAR Protocolのチームには、シャーディングの構築を担当する3人の元MemSQLエンジニア、および5名の元Googlerが在籍しており、分散型システムの構築に関する業界の専門知識を持っています。

 

シャーディングのことをBeanstalkと呼ぶ

この記事を通して、シャーディングのことをBeanstalkと呼ぶことにします。

シャーディングは、演算処理をする際に複数のノードにトランザクションを分割します。分割されたノードを「shard(以下 シャード)」と呼びます。各シャードには独自のバリデーターのセットがあります。そしてPoWのマイニングや投票による検証によってブロックを生成する参加者を、「バリデータ」と呼びます。

Beanstalkの設計は、シャーディングにおけるいくつかの課題を概説するのに十分な役割を果たします。

 

Validator partitioning and Beacon chains

シャーディングにはいくつかの課題が存在するとお伝えしました。

1つ目の課題は、分割されていないX個のバリデーターを持つ1つの大きなチェーンが10個のシャードに分割する場合、各シャードはX/10個のバリデーターを持つことになります。そして各シャードに独自のバリデータが存在することになります。しかし、各シャードの安全性がチェーン全体の1/10になったことを意味しており、1つのシャードを破壊するにはバリデータの総数の5.1%(51%/10)への攻撃で可能となってしまいます。

2つ目の課題は、それぞれのシャードに対して誰がバリデータを決定するのかということです。5.1%のバリデーターがすべて同じシャード内に入ってしまった場合大きな問題になります。バリデータがどのシャードに含まれるかを選択できないことが望ましく、システムを危険にさらす可能性が大幅に低下します。

現在提案されているシャーディングは、バリデータを各シャードに割り当てる際にランダムネスに基づいています。ランダムネスによるバリデーターの割り当てにはシャード毎に計算を必要とします。よって既存の設計では、ネットワーク全体を保持するのに必要なオペレーションの実行を委任された別のチェーンを保持しています。これらのオペレーションには、ランダムネスの生成やシャードへのバリデータの割り当てのほかに、シャードの更新とそのスナップショットの取得、PoSによるステークの処理とスラッシング、およびシャードの調整が含まれています。

このようなチェーンは、EthereumやNEAR ProtocolではBeacon chains(以下 ビーコンチェーン)、PolkaDotではRelay chain、CosmosではCosmos Hubと呼ばれています。

 

Quadratic Sharding

シャーディングはネットワークに参加しているノードの数に応じて無数に拡大するソリューションです。理論的にはそのようなシャーディングソリューションを設計することは可能ですが、ビーコンチェーンの拡張性には制限があります。ビーコンチェーンはそれ自体が単一のブロックチェーンであり、演算を実行するノードの計算能力によって制限されるため、シャードの数も自然に制限されていきます。

ネットワーク内のノードの効率が恣意的に改善され、トランザクション処理時間が短縮される場合を考えてみましょう。

例えば、ビーコンチェーン内のノードを含めてネットワークを運用しているノードが4倍高速になると、各シャードは4倍以上のトランザクションを処理することができ、ビーコンチェーンは4倍以上のシャードを処理できるようになります。システム全体のスループットは4 x 4 = 16倍に増加します。これがQuadratic シャーディングです。

現時点で実行可能なシャード数を正確に測定することは困難ですが、将来的にユーザーのニーズがQuadratic シャーディングの処理できる上限を上回ることは考えられません。このような量のシャードを安全にオペレートするために必要なノードの数は、現時点でネットワーク内に存在するノードの数よりも桁違いに多くなります。

Exponential シャーディングという提案も活発的に行われています。これはシャードがマークル木を形成していき各親シャードは子シャードを編成します。子シャードは他の親シャードの子になることができます。

POINTQuadratic シャーディングはメインチェーンの下に分割された単一のシャードを形成する提案で、Exponential シャーディングは、分割されたシャード(親シャード)の下にシャード(子シャード)を形成する提案です。

 

State Sharding

ブロックチェーン内のノードは3つの重要なタスクを実行します。

1)トランザクションの処理。

処理をするトランザクションの数が増えるにつれて、より多くの処理能力が必要になります。

2)検証済みトランザクションと完成したブロックを他のノードに中継。

中継されるトランザクションとブロックの数が増加するにつれて、より多くのネットワーク帯域幅が必要になります。

3)ネットワーク台帳全体のステート(状態)と履歴を格納。

ステートが大きくなるにつれてより多くのストレージが必要になります。重要なのは、トランザクションレート(1秒あたりに処理するトランザクション数)が一定の場合でも、ストレージは増大するということです。

上記よりストレージの増大が大きな問題に感じるかもしれませんが、実際の大きな問題は処理能力です。この記事の執筆時点でのEthereumの全体のステートは100GBで、ほとんどのノードで簡単に管理できています。しかし、多くのユースケースに必要な数よりも随分少なくなっています。

実際には、各シャード内のノードは割り当てられているグローバル・ステートのローカル部分にのみ影響するトランザクションを含む独自のチェーンを構築しています。したがって、シャード内のバリデーターは、グローバル・ステートのローカル部分のみを保管して、そのステート部分に影響を与えるトランザクションのみを処理する必要があります。この作業の分割は、すべての処理能力、ストレージ、およびネットワーク帯域幅に対する負担を低減しますが、データの可用性やCross shard transactions(以下 クロスシャード・トランザクション)などの新しい問題を引き起こします。

 

Cross shard transactions

事例として前述したBeanstalkは、各シャード間で相互にコミュニケーションが取れない場合、有用なアプローチとは言えません。このシャード間の相互運用性には大きな課題があります。

ネットワークの各参加者が1つのシャード内にアカウントを持ち、決済をした場合を例に考えてみましょう。同じシャード内で口座から別の口座に送金する場合は、そのシャード内のバリデーターによってトランザクションを処理することができます。しかし、シャード#1(別シャード)に住むアリスがシャード#2(別シャード)に住むボブにお金を送りたいのであれば、シャード#1のバリデーターもシャード#2のバリデーターもトランザクションを処理することができます。

クロスシャード・トランザクションには、2つのアプローチがあります。

  • 同期(Synchronous):クロスシャード・トランザクションが発生した際には、トランザクションに関連したステートを含む複数のシャード内のブロックがすべて同時に生成され、複数のシャードのバリデーターがトランザクションの処理に関して協力をします。
  • 非同期(Asynchronous):クロスシャード・トランザクションが発生した際に非同期で処理が実行されます。この方法は調整の容易さにより一般的になる傾向があり、現在Cosmos、Ethereum Serenity、NEAR、Kadenaなどで提案されています。問題点として、ブロックが独立して生成された場合、複数のブロックのうちの1つが孤立する可能性があるため、トランザクションが部分的にしか適用されないことがあげられます。以下の図は、2つのシャード(シャード#1 シャード#2)でハードフォーク発生後に対応したブロックAとX ‘に記録されたクロスシャードトランザクションを示しています。チェーンA-BとV’-X’Y’Z ‘が対応するシャードが正規のものとして承認された場合、トランザクションは完全にファイナライズ(確定)します。A’-B’-C’-D ‘とVXが対応するシャードが正規のものとして承認された場合、トランザクションは完全に放棄されます。しかしこれは許容範囲です。しかし、ABとVXが正規のものとして承認された場合は、トランザクションの一部がファイナライズされ、一方が破棄されて障害が発生します。

チェーン間の相互運用性(インターオペラビリティ)は、多くのプロジェクトが解決しようとしている重要な問題です。シャードとして分割されたブロックチェーンのブロック構造とコンセンサスは、シャード間で同じなので問題に対するハードルを低減しています。しかし、すべてのシャードチェーンは同じですが、様々なブロックチェーンエコシステムでは、ターゲットユースケース、分散化、およびプライバシーの保証に関してそれぞれ異なります。

 

悪意ある行動

最後に理解しておくべき重要事項があります。

それは、悪意のあるバリデータがどのような攻撃を実行できるのかということです。

悪意のあるフォーク

悪意のあるバリデータがハードフォークを試みるかもしれません。採用しているコンセンサスがBFTであるかどうかは関係ありません。バリデータの数が減少すれば常にハードフォークができるようになります。

ネットワーク全体の50%以上が破壊されてしまうよりも、単一のシャードの50%以上が破壊されてしまう可能性の方が非常に高いことを前述しました。さらにクロスシャードトランザクションは複数のシャードのステート変更を含み、そのようなステート変更を適用するシャード内のブロックはすべてファイナライズされるか、または孤立してしまう可能性があります。一般的にシャードが破損する可能性は無視できないので、シャードとバリデータ間でビザンチンの合意が得られた場合や、ステートが変化してブロックの上に多数のブロックが生成された場合でも、ハードフォークは発生しないとは言えません。

この問題には複数の解決策がありますが、最も一般的な解決策は最新のシャードチェーンからビーコンチェーンのクロスリンクです。次に、シャードチェーン内のハードフォークルールが変更されて、常にクロスリンクされているチェーンが優先され、最後のクロスリンク以降に公開されたブロックにのみシャード固有のハードフォークルールが適用されます。

次にフォークルールとは何かについて詳しく説明します。

無効なブロックの承認

一連のバリデータが、ステート遷移関数を使って誤ったブロックの作成を試みる可能性があります。たとえば、Alice10個のトークンを持ち、Bob0個のトークンを持つ状態から始めて、ブロックにはAliceからBob10個のトークンを送信するトランザクションが含まれる場合があります。

ネットワーク内のすべての参加者がすべてのブロックを検証し、そのような無効なステート遷移を持つブロックは他の両方のブロックプロデューサおよびネットワークの参加者によって拒否されるため、従来の分割されていないブロックチェーンではそのような攻撃は不可能です。たとえ悪意のあるバリデータが、正直なバリデータよりも速く無効なステート遷移を持つブロックの上にブロックを作成し続け、無効なブロックを持つチェーンが長くなったとしても、問題ありません。すべてのブロックを検証し、無効なブロックの上に構築されたすべてのブロックを破棄します。

上の図には5つのバリデータが存在しており、そのうちの3つは悪意のあるものです。彼らは無効なブロックA ‘を作成し、その上に新しいブロックを構築し続けました。2人の正直なバリデータが無効なものとしてA ‘を破棄した後に、有効なブロックとしてAをフォークしました。正直なフォークブロックにはバリデータが少ないので、チェーンは短くなっています。ただし、従来の非共有ブロックチェーンでは、何らかの目的でブロックチェーンを使用するすべての参加者は、受信したすべてのブロックを検証してステートを再計算する責任があります。したがって、ブロックチェーンに興味を持っている人なら誰でも、A ‘が無効であることを確認し、したがってB’C ‘およびD’もすぐに破棄し、チェーンABを現在の最長有効チェーンと見なします。

ただしネットワーク参加者は、シャードとして分割されたすべてのトランザクションを検証できないため、ブロックチェーン内のシャードの履歴から無効なブロックが含まれていないことを確認する方法が必要になってきます。

ビーコンチェーンにはブロックを検証する機能がないため、クロスリンクは十分な解決策ではありません。クロスリンクを用いることで、シャード内の十分な数のバリデータがブロックに署名したことを検証することができます(したがって、その正当性が証明されています)。

この問題に対する解決策が2つありますが、現時点満足できるものではありません。

  1. ステート遷移を誤って適用しようとした場合にシステムに警告する合理的なメカニズムがいくつかあります。特定のシャード内の悪意のあるバリデータの数が2/3未満である限り、各シャードが何らかのBFTコンセンサスを実行していると仮定して、少なくとも1人の正当なバリデータがブロックを証明することで、ステート遷移関数が正しく適用されます。悪意のあるノードが2/3を超えている場合は、正直な単一のノードを参加させることなく誤ったブロックをファイナライズ(確定)させることができます。シャード内の少なくとも1つのノードは悪意がないと仮定すると、そのようなノードからどのようなブロックが生成されているかをモニターし、無効なステート遷移を持つノードを検証するための十分な時間が必要になります。
  2. ブロックには、ステート遷移が正しく適用されていることを証明するのに十分な情報を入れる必要があります。

現在、バリデータローテーションとビザンチンフォールトトレラントコンセンサスを採用しているプロトコルでは、ハードフォークや無効な状態遷移を実行することは不可能であると仮定しています。これについては次回説明します。

 

日本で初めてのNEAR ProtocolのミートアップがHashhubにて開催されます。情報の少ないNEARの最新情報を「日本語」で聞くチャンスです。席に限りがございますのでお早めにご参加ください。

[blogcard url=”https://hashhub.connpass.com/event/122030/”%5D

 

LINE@ – 友達追加 –

おかげさまで現在お友達が1057名を突破しました。仮想通貨の最新情報や重要なファンダ情報などを「プッシュ通知」にて誰よりもはやくお届けします。

https://platform.twitter.com/widgets.js

CoinPicks Labってなに?

The Beginner’s Guide to the NEAR Blockchain – NEAR Protocol 入門書編 –

NEAR Protocolの入門書ともいえる記事を和訳しました。全文の中から日本人でも理解がしやすいように筆者独自の表現に変換している部分が多々ありますのでご了承ください。こちらの記事を読んでいただくことで、NEAR Protocolが市場に何をもたらすのかを理解いただくことができます。


NEAR Protocolの日本版テレグラムはこちらから参加頂けます。

[blogcard url=”https://t.me/joinchat/GLZiexXRiYpYEwwNH3znPQ”%5D

 

The Basics

こちらの記事は、NEARに関して興味がある人のサポートをすることを目的としています。実際にNEARの活動状況をお伝えして、NEARに参加するためにどのような知識が必要になるのかを理解して頂けるような記事になっています。

 

NEARとは何か?

簡単にいうとDeveloper FriendlyなPoSブロックチェーンです。

つまり、非常にスケーラブルで低コストの分散型アプリケーションを開発するためのプラットフォームです。他の「スケーラブル」なブロックチェーンとは異なり、NEARのアプローチはノードがローエンドハードウェア(モバイルデバイスを含む)上で動作することを想定しています。

またNEARは、世界で唯一の最先端データベースシステムを構築した世界チャンピオンレベルのプログラマーを含む特別なチームを構成しており、暗号通貨の世界で最も有名な方に支援されています。

NEARは何のためにプロトコルを開発しているのでしょうか?

それはユーザー自身が資産やアイデンティティーを管理できるようにすることで、インターネット以上に優れた新たな基礎を築くチャンスだと考えているからです。

 

From 10,000 feet…

NEARは基本的に新しいWEBインフラストラクチャーを構築しています。それは大企業による個人情報の収集を難しくするのと同時に、データに対する検閲耐性を提供します。

過去Bitcoinは犯罪者と独裁者によって使用されてきました。今日まで様々な問題や議論があったにもかかわらず、Bitcoinは殺されることなく10年という月日が経過しました。これは分散性と柔軟性を兼ね備えた技術の上に構築されているからです。

Ethereumも同様に、新たなインターネットの構築に取り組み良いスタートを切りました。しかし、結局は初期の技術の成長痛のように開発は行き詰まり、メインストリームに適応するために多額のコストがかかっています。いま、多くの人たちがコストを低く抑えるための方法について試行錯誤しています。

 

From 1,000 feet…

拡張性とコストの問題に取り組んでいるのはNEARだけではありませんが、NEARは優秀なチーム構成を活かして少し違ったアプローチを取っています。

NEARは「Base Layer Blockchain」として市場を整えます。

つまり、私たちはEthereum、EOS、TRON(TRX)などのプロジェクトと同様のエコシステムに属しています。つまり、開発者NEAR Protocol上に分散型アプリケーションを作成できるようにする汎用プラットフォームを構築することを意味しています。

 

The Arc of Technology

Bitcoinは「プログラム可能なお金」または「デジタルゴールド」です。

その機能を果たすために素晴らしい働きをしてきましたが、(私たちが構築しているような)より汎用性の高いコンピューティングプラットフォームとしての利用はほとんどできません。開発者はBitcoinを信頼性と安全性が高まった新たなアプリケーションの一部として使用するようになりました。しかし、トランザクションのブロードキャストには多大なコスト発生し、処理速度は遅く(毎秒およそ4トランザクション)、世界のエネルギーを大量に浪費しています。また、もともとBitcoin上にプラットフォームを構築することを意図していなかったために機能が限られています。

Bitcoinが単なる演算処理機であるならば、Ethereumはゲームを構築することができる空想的なTI-83グラフ演算機(*1)です。様々なアイデアが導入されているものの処理速度は遅く(毎秒14トランザクション)、多大な費用が必要です。これらの問題を解決しようとしても、すでに動き出しているワールドコンピュータをアップグレードすることは困難と言えます。

*1:1996年にTI-82の後継としてリリースされ、欧米では生徒や学生がよく使った。通常の関数電卓としての機能だけでなく、関数のグラフ表示、統計機能などを備えている。どんな計算機能も持っているというわけではないが、プログラムをWebサイトからダウンロードしたり新たにプログラムを書くことが可能となっている。Wikipedia引用

「ステートチャネル」や「サイドチェーン」などの「レイヤー2」スケーリングソリューションは、メインチェーンから一部の作業を取り除き、パフォーマンスを向上させることで、これらの低速(ではあるが安全な)プラットフォームのパフォーマンスとコストを改善しようとしています。このアプローチはBitcoinとEthereumの両方に存在しますが、期待を上回るような成果は得られていません。

2017年から2018年にかけて、多くのプロジェクトがスケーリング問題を解決するために様々なアプローチを取り入れました。彼らは分散化を犠牲にすることで(例えばEOSのように)毎秒数千(またはそれ以上)のトランザクションのスループットを達成しました。しかし、ネットワークを構成する「ノード」が21個であろうが、1,000個であろうがそれぞれが全く同じ仕事を繰り返しているので処理速度に限界があります。

次世代のスケーラブルなブロックチェーンNEAR Protocolのようなプロジェクトは新たなイノベーションを起こします。NEAR Protocolは、ネットワークに参加する全てのノードが全てのトランザクションを検証する作業からを解放されます。

NEAR Protocolは、データベースの世界から「Sharding(以下 シャーディング)」と呼ばれるテクノロジーを使用して、ネットワークを分割することで演算処理の大部分を並列的に行うようにしました。シャーディングを導入することでネットワーク内のノード数の増加に伴い、ネットワークの容量を拡大することができるため、ネットワークの容量に理論的な限界はありません。

他のプロジェクトは、複雑化するハードウェア上でノードを実行する必要があり、ネットワークに参加するためにより多くの労力が必要になります。NEAR Protocolが採用するテクノロジーは(潜在的にモバイル機器のような)ローエンドハードウェア上で動作できるように、ノードを限りなく小さく保つことで多くのユーザーからのアクセスを可能します。結果ネットワークの規模の拡大と分散化を実現します。

 

NEARが構築する分散型ネットワーク

前述したように、NEARプロトコルは分割されたDeveloper FriendlyなPoSブロックチェーンで、開発者はNEAR Protocol上に分散型アプリケーションを構築することができます。

NEARが実際に行っていることを詳しく見てみましょう。

NEARは、現在開発者がアプリケーションを構築するために使用している「クラウドベース」のインフラストラクチャに似ています。データセンターが単一の企業によって管理されているクラウドと比較して、NEARは分散型ネットワークのノードを運用している世界中のすべての人々によって管理しています。

この分散化がなぜ有用なのかについて2つの視点から説明します。

  1. 開発者 / 起業家:このようにアプリケーションを分散させるのは良いことです。開発者としては、Amazonのような単一の会社や政府にアプリをシャットダウンされる心配がありません。歴史を振り返ると企業は単一の会社や政府に殺されてきました。また、開発プロセス中に決済や暗号化など、いくつかの機能にアクセス可能です。これは、従来のアプリケーションでは設定するのが難しい場合があります。
  2. エンドユーザー:コードはすべてオープンソースであるため(それが実際に何をしているのかを正確に把握しているため)、また起動したら変更できないため(だから開発者はあなたのお金やデータを搾取することはできない)、分散型アプリケーションを使用するほうが良い場合があります。さらに素晴らしいことにこのアプリケーションはあなたのデータを蓄積することはないのです。

このネットワークがどのように動作するかをもう少し詳しく調べてみましょう。

 

The NEAR Token

では、実際には誰が分散型ネットワークを構成する個々の「ノード」を運営するのでしょうか。

それはNEARトークンの保有者です。

NEARトークンは、Taxi Medallion(タクシーメダリオン)のように機能します。ニューヨーク州でタクシードライバーになるには「タクシーメダリオン」が必要です。メダリオンは、あなたがタクシーサービスを提供することでお金を稼ぐことを許可都市からの免許です。同様に、NEARトークン保有者は自分のコンピュータを使用してネットワーク上のノードを運営ですることができます。

では、ノードを運営するインセンティブは何でしょうか?

ユーザーはノードを運営することで、ネットワークから取引手数料を得ることができます。これは「Proof of Stake」システムであるため、より多くのトークンをステークするほどにネットワークへの貢献ができ、より多くの手数料を得ることができます。

ユーザーは自身のトークンを「ステーク」(これは基本的には保証金のように預託金にすることを意味します)することでネットワークに対する誠意を示す必要があります。あなたが何らかの悪意のある行動(システムをハックしようとしたり、他人の取引を混乱させようとするなど)を実行するとステークが没収されます。

 

NEARはどのようにして利益を得るのか?

NEARの収益源は「トークン」です。

ブロックチェーン業界で重要なことはビジネスとしてのユースケースを考え出すことです。バブル機において、実際にはトークンを必要としない複雑化した収益化スキームを見てきました。NEARトークンにどのような価値があるのかを説明するのはとても簡単です(上記の「タクシーメダリオン」のアナロジーを参照してください)。NEARトークンが実際にどのように発行されるのか、そしてNEARの「ビジネス」が実際には何を提供するのかを説明しましょう。

まず第一に、ネットワークは最終的に分散化されることを意図しています。つまり、最終的には自律稼働することで第三者による検閲やネットワークの切断等による心配はありません。これが基本的なポイントです。 しかし、完全に分散化されたネットワークを自律稼働するためには、NEARのチーム自身がブートストラップする必要があります。

NEAR Incは、スペースシャトルのロケットブースターのように、このテクノロジを実現するために設立された企業です。その仕事は、オープンソースのブロックチェーンを構築して軌道に乗せるために必要な開発作業を行うことです。それは文字通り誰でもコードの中身を見ることができるようなオープンソースです。コアチームは、システムの更新とバグの修正を続けることができます。この企業の従業員と投資家は、連鎖的にコード化された最初のトークンのバッチの割り当てを受け取ることで、自身の仕事に報酬を与えます。

NEAR Foundationは、ブロックチェーンに関連したアクティブなエコシステムを構築することを目的とした非営利団体です。このFoundationは、最終的にNEARブロックチェーンを運営します。Foundationがこのシステムに関する強力な専門性を持ち、このエコシステムを成功させるために継続的な寄付を行っているため、最終的には多くの人々に受け入れられることを期待されています。オープンソースであるがゆえにNEARブロックチェーンのコードを誰でも自身のチェーン上にコピーして使用することができます。

 

何を目指すのか?

この市場のプロジェクトは、多くの個人投資家がICOへの参加を促すことに重点を置いていました。それは、大きなテレグラムコミュニティを持ったり、有名なアドバイザーを抱えたり、大企業からの見栄えの良い実証プロジェクトを手に入れることなどを意味しています。

NEARには、コードが正確に実装されているかどうかを確かめるために働いている素晴らしいテクニカルチームがあります。彼らが構築するものはすべてオープンソースになるでしょう。そしてチームの専門知識と継続的な開発努力は、市場を大いに前進させます。しかし、テクノロジーは単なる時間効率を高めるのみで、最も重要なことは素晴らしいコミュニティを築くことです。

上述したようにトークン価値の源泉は、保有者に与えられる取引手数料です。ネットワーク上のアクティビティが多いほどに保有者が利益を得ることができトークン価値も上昇します。よってNEARはプラットフォームへの採用にコミットします。

さらに重要なことは、大量のプラットフォームへの採用を目的にするのではなく、規模の大きなプラットフォームやプロジェクトに対するサポートです。そのために機能的な幅と技術的な深さを持つエコシステムを構築することが私たちにとって大切です。そのためには、コミュニティの構築、教育、および全体的なユーザーエクスペリエンスの面で大きな努力が必要です。

幸いなことに、成功すればインターネット以来最大のイノベーションと富を創造する機会になります。

 

NEARが市場で勝者となり得る理由

NEARが市場で勝者となり得る要素を2つの観点から捉えることができます。1つはNEAR Protocolこそが最善の選択肢であること、もう1つはNEAR Protocolが開発者やユーザーにとってより良いものだということです。

 

Execution Matters

私たちのウェブサイトを見てください。

分散型システムの構築経験がある業界で最高のチームであることを知るでしょう。この時点で他のプロジェクトとは一線を画しています。

このテクノロジーは複雑です。技術的に言えば、シャーディングは市場をリードするEthereumを含むいくつものチェーンで真剣に試みられているスケーリングアプローチです。しかし彼らは提案をまとめるのに何年もかかり、それを実行するのにより長い年数がかかると予想しています。シャーディングの実装は簡単なことではありません。

 

開発者とエンドユーザー

市場の現状はとして何百ものチームが独自のプログラミング言語を使用しておりベクトルも異なっています。それは混乱を招き非効率と言えます。

ユーザーが暗号通貨ベースのアプリケーションを使用するまでには非常に長い時間を必要とします。また、ゲームをプレイしたり友達にお金を送ったりするためには、文字通り数十の手順が必要です。これではローンチ前に多くのユーザーが離れていきます。

テクノロジーによって市場がどのように変化していくのかを見るのではなく、テクノロジーを生み出す原動力として、ユーザーエクスペリエンスとユーザーニーズの向上に焦点を当てることが大事です。NEARはこれらの問題を解決するためにより広くコミュニティに関わりながら、サポートするためのツールを開発しています。簡単なことではありませんが、それは「現在」NEARにとっての優先事項となっています。

だからこそ、私たちはNEARを「Developer Friendly」または「Usable」と表現しています。

開発者がアプリケーションを作成し、ユーザーがそれらを採用するのを容易にするようにプロトコルレベルでアプローチしていきます。開発者にとっては、使い慣れたTypeScriptを使用して、アプリの構成を簡単にする一連のツールを構築します。エンドユーザーにとっては、アカウントの設定方法に、より多くの手順や迷惑なウォレットのポップアップを必要としないスムーズなオンボーディングエクスペリエンスを可能にします。

 

NEAR Protocolのユースケースとは?

実際にはブロックチェーンのユースケースについて、サプライチェーンの追跡から国境を越えた支払いなどに使用されていますが、開発段階も初期フェーズであるがゆえに実需としての採用はされていません。

本当にスケーラブルなブロックチェーンが、新たなビジネスの開拓にどのように役立つかについて、既存のビジネスや多くの起業家たちと話をしています。問題を解決するために人々がNEARに期待しているホットな領域がいくつかあり、既存のブロックチェーンが抱える課題はユーザーにとって良いものではありません。

長い目で見れば、初期のインターネット革命と同様に人々がまったく新しいビジネスモデルを発明するまでの間のギャップを埋めることになるでしょう。特に将来の起業家が想像もできない方法で世界を変えることができるツールを構築できることにNEARチームは興奮しています。

NEAR Protocolの日本版テレグラムはこちらから参加頂けます。

[blogcard url=”https://t.me/joinchat/GLZiexXRiYpYEwwNH3znPQ”%5D

原文

 

LINE@ – 友達追加 –

おかげさまで現在お友達が1057名を突破しました。仮想通貨の最新情報や重要なファンダ情報などを「プッシュ通知」にて誰よりもはやくお届けします。

https://platform.twitter.com/widgets.js

CoinPicks Labってなに?

ERC725とERC735について学びDappsのユースケースを考える

個人情報(ID)を分散的に管理するためのイーサリアムの規格ERC725とERC735について概要を説明し、そのミドルウェアとしてOriginProtocolを紹介しています。この記事を読んでいただくことで、分散的な個人情報の作成、管理、使用方法まで把握して頂くことができます。


ERC725とERC735について

ERC725とは

ERC725は、ID(アイデンティティ)の管理を中央集権的な組織で管理するのではなく、イーサリアムのブロックチェーン上で分散的に管理するために提案された規格です。

この規格は、ERC725は、ERC 20およびWeb3.jsの作成者であるFabian Vogelstellerによって作成されました。

Vogelsteller氏は次のように説明しています。

「アイデンティティー(ID)は、確かにブロックチェーンエコシステムで欠けている最も重要な要素の1つです。」

ERC725の規格を用いて発行されたIDは、トランザクション、文書、ログイン、アクセス、およびClaim(*1)に署名するためのKey、およびプロキシ機能を保持することができます。

*1 Claimプロファイルデータを指しており、名前、説明、プロフィール写真などです。

このIDには複数のKeys(外部アカウントまたはコントラクトアドレスからの公開鍵)を紐づけることができます。

 

ERC735とは

ERC735は、IDスマートコントラクトに対してClaimを追加および削除するための関連規格です。

Claimの追加、削除、および保留のための標準機能であり、Claimは第三者(発行者)から証明することも自己証明することもできます。この標準化されたインターフェースにより、DappsとスマートコントラクトはClaimホルダーを確認することができます。

 

認証方法

たとえば、DappsとERC725及びERC735を用いてAirbnbのようなサービスを構築することができます。仲介者を省くことで大きなコストの削減が可能になります。しかし、あなたが家を借りる人を信頼できなければ家を貸し出したいと思わないでしょう。

どのようにして個人を識別するのでしょうか?

下記3つの立場から説明します。

  • ICO実施会社
  • IDプロバイダー
  • 投資家
  1. IDプロバイダーはIDコントラクトをデプロイします。
  2. IDプロバイダーIDコントラクトにkyeを追加します。
  3. 投資家は自分のIDコントラクトをデプロイします。
  4. 投資家が正常にKYCを受けた後、IDプロバイダーは投資家のKYCに対してのClaimに署名します。
  5. 投資家はIDプロバイダーの署名入りKYCIDコントラクトに追加します。
  6. ICO実施会社はトークンセールコントラクトをデプロイします。
  7. 投資家は自身のIDコントラクトを通じて、ICO実施会社ICOに参加します。
  8. ICO実施会社は参加の承認以前に、投資家のIDコントラクト内にあるClaimに対して、IDプロバイダーによるに署名が含まれていることを確認します。

 

OriginProtocolについて

OriginProtocolは、イーサリアムブロックチェーン上で仲介業者による市場管理の必要性を代替する機能を提供し、オープンで公正かつ透明な規則によって管理される市場を作成することを可能にします。

最新リリースには、ユーザーIDのサポート(ERC725 ID標準のサポート)、トランザクション手順、エスクロー、評価、およびレビューなど、多くの新機能が詰め込まれています。しかし、UX(ユーザーエクスペリエンス)と全体的な機能性にいくつかの改善が必要とのことです。

ERC725の実装によってユーザーは自分のIDをイーサリアムウォレットに接続することで、自分のIDコントラクトを作成と制御が可能になります。

名前、プロフィール写真、または経歴を追加したい場合は、その情報をIPFS(InterPlanetary File System)に公開し、結果のハッシュをイーサリアムブロックチェーン上に保存します。電話番号、電子メールアドレス、ソーシャルメディアのユーザー名などの機密性の高い情報については、その存在を証明するものだけを保存します。

世界には銀行口座が開設できないことによってUberAirbnbのような人気のあるアプリを使うことができない人が約20億人存在します。しかし、多くの人々がスマートフォンを持っています。したがって、彼らは今後数年間で構築される暗号通貨と分散型市場にアクセスできるようになります。

OriginProtocolシステムの中心となる部分は、ユーザーがIDデータを作成、更新、および読み取ることを可能にする分散型Dappsです。

Dapps内からのIDの作成または更新には、以下のステップが必要になります。

  1. ユーザは自分が公表したいと思うClaimデータを入力します。たとえば、名前、簡単な説明、プロフィール写真などです。
  2. 任意選択で、ユーザは自分のClaimにいくつかの証明を追加することができます。たとえば、電話番号が自分のアカウントに関連付けられていることを示す証明を追加することを選択できます。それらを生成するために、Dappsはリクエストをアテステーション・サーバーに送信し、署名されたアテステーションを受信します。
  3. 最後のステップは、ユーザーが自分のIDを公開することです。まず、Claimと検証済みのアテステーションで構成されている自分のプロファイルが、JSONデータのBLOBとしてIPFSにアップロードされます。次にDappsが動作することにより、そのデータのIPFSハッシュを記録するスマートコントラクトへの呼び出しを行います。

ユーザーのIDを読み取るには、ユーザーのイーサリアムアドレスに関連付けられているIDをスキャンして最新のIPFSハッシュを取得し、次にIPFSから最新のIDデータをロードする必要があります。

アテステーションサーバーは、OriginProtocolの分散型アプリケーションと電子メール、電話、ソーシャルネットワークなどの集中型システムとの間のブリッジとして機能します。Dappsから要求を受信すると、アテステーションサーバーはユーザーからの要求を検証しようとします(たとえば、ユーザーが電話番号、電子メール、またはソーシャルハンドルを実際に所有していることの検証など)。検証方法の種類は、Claimの種類自体によって異なります。OriginProtocolはユーザーの個人情報をブロックチェーンに書き込むことはせず証明に署名し、要求によってDappsに送信します。

OriginProtocolに対して、ユーザーの要求に対する検証について質問をしました。

Point:How do you prove that KYC is correct?(KYCが正しいことをどのように証明しますか?)

以下のような返答を頂きました。

We use a standard verification process where a random code is generated and the user has to either enter in that code or log into their Email/Twitter/Facebook/Airbnb and enter the code to prove they have access and own that account.

KYCの実施時にランダムコードが生成され、そのコードを認証しようとしているプラットフォーム(Email / Twitter / Facebook / Airbnb)などにログインして入力する必要があります。これによってユーザー自身がアクセス権限を所有していることの証明ができるとのことです。

 

まとめ

ERC725とERC735について説明した後に、それらの規格を活用したミドルウェアとしてOriginProtocolを紹介しました。

これらの規格とDappsはシェアリングエコノミーとの相性が非常に良く、シェアリングエコノミー協会の一員としても非常に興味深くウォッチしています。OriginProtocol上に今後どのようなアプリケーションが乗っかってくるのかに特に注目しています。

ID(個人情報)の管理が個人に回帰され、IDの証明が統一的にできるようになればユーザーサイドとしては、かなり便利になるなと考えている次第です。また、企業サイドとしても管理業務を個人に任せることで費用の削減と漏洩リスクを減らすことができるのは大きな変化なのではないかと感じます。

ERC223についての基礎学習についてはこちらからご覧ください。

[blogcard url=”https://atomic-temporary-106217043.wpcomstaging.com/ethereum-erc223/”%5D

Join Lab Now

 

Mimblewimbleについて日本語で理解する

Mimblewimbleに関する情報サイトが公開されました。どんな情報サイトなのか簡単な紹介をさせて頂きます。


Mimblewimbleの情報サイト

Mimblewimbleに関する情報サイトが公開されました。

Mimblewimble(以下MW)に関する歴史から基礎知識、そしてプロトコルに使用されている技術に関する説明を大変わかりやすく説明して頂いています。ホワイトペーパーやgithubでMWに関する知識を得ようとしても専門的な用語や難しい言い回しが多く、せっかく興味をもって調べはじめた初心者のハートをブレイクしてしまいます。

それに相場の影響もあってか、まだまだ日本ではMWに関する認知が低いのも現状です。(聞いたこともないという人も以外と多いのではないかと思っています。)

下記サイトであれば、日本語でMWに関する豊富な知識を得ることができるので、ぜひ一度目を通してみてください。

https://mimblewimble.jp

サイトの中身を少し紹介させて頂きます。

「Mimblewimbleの短い歴史:ホグワーツからモバイルウォレットへ」

MWの歴史について学ぶページです。

MWの歴史を語る上で必ず紹介されるハリーポッターとの関係についてからはじまり、誰がどのようにしてMWを世に広め、MWを実装したGrinやBEAMがどのように誕生したかまで学ぶことができます。

2019年の暗号通貨界隈でひとつのキラーワードになるであろうMWと、それを実装したGrinとBEAMのについて今後より一層注目を集めることとなるでしょう。

 

CoinPicks LINE@

おかげさまで現在お友達が1057名を突破しました。仮想通貨の最新情報や重要なファンダ情報などを「プッシュ通知」にて誰よりもはやくお届けします。

https://platform.twitter.com/widgets.js

CoinPicks Lab

学習項目
 
  • 分析レポート
  • Bitcoinについて
  • Ethereum経済圏について
  • ST(セキュリティートークン)について
  • PoS型プラットフォームトークンについて
  • ステーブルコインについて
  • コンセンサスアルゴリズムについて
  • トークン設計について
  • 流通設計について
  • CBDCについて
  • 各インフルエンサーによる特化した情報
  • Q&A項目の共有
  • 基礎学習
  • 掲示板

https://lounge.dmm.com/detail/761/

などなど…
今後も学習項目は増えていきます。