dApp Technology Stack

dApp Technology Stack

Casper Networkと疎通する分散型アプリケーションのビルドには3つのレイヤーがあります。それは、フロントエンドとバックエンド、そしてオンチェーンロジックです。この章の概要では、それぞれに必要なものを列挙しています。

フロントエンド

フロントエンドまたはdAppのclient-side は、ユーザーがCasper Network上のスマートコントラクトとの疎通に使用するインターフェイスにて成り立っています。このインターフェイスは、website/webpageやモバイル端末アプリケーション、コンピュータープログラムといった形状のものが殆どですが、呼び出しやクエリが可能なエンドポイントを持つAPIもそれに含まれます。

Casper Network上のスマートコントラクトを呼び出したりクエリする際に使用する言語に合わせてCasper SDKを選択する必要があります。CasperのSDKには、Deployの構造化やグローバルステートのデータ収集を有効とするメソッドが組み込まれています。フロントエンド側にこの疎通の仕組みを持たせるため、ネットワークに送信する前にアプリケーションのバックエンド側へ送信する必要があります。そうすることで、CORS問題を解決できます。

トランザクションへの署名

殆どの場合、トランザクションへの署名はフロントエンドにてユーザーによる操作が必要であり、いくつかのオプションがあります。

  1. Casper Wallet
    Casper Wallet は、Casper Wallet を用いてCasper Networkへのデプロイへの署名を行います。デプロイオブジェクトは、まずJSONへ変換され、Walletに送信後、署名されます。そして、バックエンドへ送信されノードへ転送します。

    ⚠CAUTION
    Casper Signerは廃止され、Casper Wallet（更新中）に変わりました。暫くは、Building with the Casper Walletを参照してください。
  2. Third-party signers（第三者による署名）
    Third-party signerも同様に利用可能です。未署名トランザクションのJSON形式のものが第三署名者に送られ、署名済みのデプロイオブジェクトを持つコールバックが承認されます。

グローバルステートへのクエリ

スマートコントラクトのデータや現行のチェーン情報の取得など、グローバルステートへのクエリを実行するにあたり、フロントエンド側での準備が完了していたとしても、ノードへのクエリは最終的にはアプリケーションのバックエンド側から発生しなくてはなりません。この準備段階は、コントラクトハッシュが定義している形やクエリしたいデータのパスのみ使用できます。他、チェーン情報の場合は、クエリしたいエンドポイントを定義する必要があります。

バックエンド

dAppのバックエンドは、フロントエンドインターフェイスにブロックチェーンを繋げ、データ分析やアプリケーションレイヤーのコミュニケーションを扱うserver-sideコードで成り立っています。バックエンドサーバーは、Casperのノードが受信したHTTPリクエストに指定オリジンからのCORS headersを必要とする為、Casper上のdAppsのビルドに必要です。バックエンドサーバーは、リクエストの待機やdAppとブロックチェーン間を移動するトラフィックの分析など、他理由においても必要です。

dAppのバックエンドサーバーはCasperノード（ブロックチェーン）とコミュニケーションをとるソフトウェアである為、どのノードやエンドポイントに繋げるのか、といった情報も受信します。

const client = new CasperClient("http://NODE_ADDRESS:7777/rpc");
client = NodeClient(NodeConnection(host = "NODE_ADDRESS", port_rpc = 7777))

💡TIP
オンラインのピア（peer）は、Mainnetのcspr.live か testnetの testnet.cspr.live にて見つけられます。

フロントエンドから発生するブロックチェーンとの疎通には、主にデプロイとクエリの2つあります。dAppの場合は、その両方ともがバックエンドに渡されます。

状態をクエリするブロックチェーンとの疎通は、バックエンド側のみでハンドルされます。フロントエンド側では、ユーザーがクエリしたいデータのパスを単に選択するのみとなります。サーバーが状態クエリを実行しフロントエンド側に結果を送信するバックエンドにこのパスが送信されます。

dAppのフロントエンドから発生したユーザーが署名済みのトランザクションの場合は、バックエンドはこのトランザクションを受理しCasper Networkに転送します。これは、時々JSON形式のトランザクションを受理し一緒に転送するPOSTエンドポイントをオープンにすることで実行されます。

Blockchain

デプロイやクエリの最終経路は、ブロックチェーンそのものです。大半のスマートコントラクトブロックチェーンの様に、Casper Networkは永久的に稼働し、読み書きが可能なイミュータブルなレジャーを運用しています。Casper NetworkのdAppをビルドする際は、フロントエンドから発生しているクエリやデプロイ形式でのユーザーインタラクションは、バックエンドに転送された後、ブロックチェーンとの疎通のためCasperノードに送信されます。JSON RPCコールを使用したCasperノードとのやり取りやtransactional や informational, Proof-of-Stake などのオープンなエンドポイントを持つことができます。バックエンドにてSDKを用いることで、自身でJSON RPCコールを実装する必要がなくなり、有効なメソッドによって対応してくれます。

多かれ少なかれ、dAppにて自身の機能の実行やカスタムデータの格納、そして恐らく金銭的な価値を持つトークンの保有や取引も行うでしょう。それら全てをカスタムスマートコントラクトを自身のアプリケーション用に書くことで実装可能となります。Casper Network上のスマートコントラクトは、一般的なコンピューターが持つ機能は実行できます。Casperのスマートコントラクトは、WebAssembly バイナリとして実行されWebAssemplyにコンパイルされるどの言語でも書くことができます。現時点では、殆どの開発者は、信頼性と使い勝手の良さのため Rustでスマートコントラクトを書いています。また、CasperのスマートコントラクトについてのドキュメントはRust用に書かれています。

スマートコントラクトの書き方については、smart contract documentationを参考にしてください。