- Developers(開発者ガイド)概要
- 開発の事前準備
- 必須となるRust Crate(クレート)
- Writing On-Chain Code
- Getting Started with Rust
- Getting Started with AssemblyScript
- 基本的なスマートコントラクトをRustで書く方法
- スマートコントラクトのテスト
- スマートコントラクトのアップグレードとメンテナンス
- スマートコントラクトの呼び出し
- コントラクトとセッションコード
- セッションコードの書き方
- セッションコードのテスト
- コントラクトによるイベント発行を有効に
- コントラクトハッシュとパッケージハッシュの使い分け
- Casperスマートコントラクトのベストプラクティス
- Casper JSON-RPC API
- DAppsのビルド
- SDKクライアントライブラリ
- dApp Technology Stack
- ReactのFront-endテンプレート
- URefのアクセス権限とセキュリティへの考慮
- トランザクションへの署名
- スペキュラティブ(推測的)実行によるガス・コストの見積もり
- NCTLを使ったローカルネットワーク設定
- NCTLを使ったスマートコントラクトのテスト
- イベントの監視と消費
- CLIを使ったBlockchainとのやり取り
What is a dApp?
分散型アプリケーション(dApp)とは、ブロックチェーンや同様のピアツーピアネットワーク上に何らかのデータを持つアプリケーションのことである。
dAppがブロックチェーンと相互作用する度合いは、アプリケーションのニーズによって大きく異なります。一部のdAppはブロックチェーンを単にデータを保存するために使用し、ロジックのほとんどはオフチェーンで行われます。また、ブロックチェーン上に保存されたロジックに依存し、最低限のユーザーインターフェイスのみをブロックチェーン自体の外部に保存する場合もある。
分散型アプリケーションはどう違うのか?
分散システムは、完全なシステムまたは分散データベース(distributed database)として機能する、交換可能なマシン群で構成される。追加のマシンは、冗長性と計算能力を追加することで、システム全体を強化する。
如何なるdAppでも、何らかの形で分散型ネットワークにアクセスする必要がある。Casperネットワークでは、これは node への接続を意味する。decentralized(分散型)の側面は、この目的のために各ノードが基本的に交換可能な状況を作り出す。接続されたノードに障害が発生した場合、dAppは別のノードに切り替えて、データや機能を失うことなく運用を継続することができます。
分散型ネットワークにおける日常的な運用では、ノードのオンやオフラインが発生することがあります。このようなノードの入れ替わりは、分散型アプリケーションが単一のノードに依存している場合、ダウンタイムにつながる可能性があります。特に自分のノードを運用していない場合は、高いアップタイムを確保するために複数のノードに同時に接続する必要があります。
分散型ネットワークとの疎通
Casperネットワークと疎通するdAppの場合、JSON-RPCを介してトランザクションを送信できなくてはなりません。ノードにトランザクションを送信するということは、そのトランザクションが他のノードと gossiping(ゴシップ)するということです。当然、そのDeployが有効かつ受理されていることを前提としています。そして、Deployは実行するためのキューに含まれます。
トランザクションには、送信アカウントのコンテキストで実行される Wasm 形式の session code が含まれています。したがって、開発者はCasperネットワーク用のdAppを構築する際に、Wasmにコンパイルできる任意のプログラミング言語を使用することができます。このセッションコードは、一度だけ実行されるWasmで構成されることもあれば、グローバルステートに保存されるコントラクトコードをインストールするWasmで構成されることもある。dAppが同じWasmを定期的に実行する必要がある場合、後で呼び出されるコントラクトとしてWasmをインストールする方がガスと実行の両方の観点から効率的です。
トランザクションの送信は、dAppがグローバルステートを変更できる唯一の手段です。ガスコストはバイト単位で動作するため、同じセッションコードを繰り返し実行するのと比較すると、スマートコントラクトは長期的にガスコストが少なくなります。dAppは接続している各ノードに同時にトランザクションを送信できますが、1つのトランザクションにつき1つのノードに1回しか送信できません。
グローバルステートへのすべての関連する変更は、トランザクションの実行が成功した後に発生する。実行に失敗した場合、スタックは巻き戻され、トランザクションの実行に伴うグローバル状態の変更 はすべて元に戻される。ただし、違約金の支払いが発生するため、送信アカウントの残高を減らすことでグローバル状態に変化が生じる。トランザクションを送信するためには、アカウントはネットワークのペナルティ支払額以上の残高を保持していなければならない。このペナルティ支払いはネットワークによって異なります。公開されているCasperメインネットでは、ペナルティ支払いは2.5 CSPRに設定されています。
他のブロックチェーン・ネットワークとは異なり、Casperネットワークはコンセンサスの後に実行される。つまり、ほとんどの場合、トランザクションの実行を観察することで最終性の証明は十分である。厳重な最終性の条件として、対象のトランザクションを含むブロックの最終署名を確認することが可能です。
トランザクションを送信する際には、送信されてから実行されるまでのタイミングを考慮する必要があります。トランザクションの Lifecycle は、集中型アプリケーションで予想されるよりも長い遅延をもたらします。トランザクションは送信され、受け入れられ、ゴシップされ、最終化されたブロックに含まれ、実行されなければならない。このプロセスはネットワークによって異なる。この遅延は、接続されているピアの数や現在送信されているトランザクションの数によって増加する可能性があるため、Casperネットワークで使用するdAppを設計する際に考慮する必要があります。