第11章Webアプリケーション開発

Web 3.0 Application ArchitecturesWeb 3.0アプリケーションのアーキテクチャ

Web 3.0 apps are architected without a centralized server, so they are considered to be decentralized Apps (DApps), which are applications that execute smart contracts and run over distributed ledger technology (DLT). Smart contracts are programs that can be executed on a distributed ledger. Distributed ledgers use independent network nodes to record, share, and synchronize transactions in their respective electronic ledgers instead of keeping them in a centralized server. The code is visible to all parties, and trust is put into the code instead of a centralized third party. Distributed ledgers chronicle transactions between accounts that are recorded in multiple places. Blockchain is a type of DLT.

英語のヒント

Web 3.0アプリは中央サーバーを使わずに設計されるため、分散型アプリ（DApp）とみなされる。DAppは、スマートコントラクトを実行し、分散台帳技術（DLT）上で動作するアプリケーションである。スマートコントラクトは、分散台帳上で実行できるプログラムである。分散台帳は、中央サーバーに取引を保存する代わりに、独立したネットワークノードを使い、それぞれの電子台帳に取引を記録・共有・同期する。コードはすべての関係者に見え、信頼は中央の第三者ではなくコードに置かれる。分散台帳は、複数の場所に記録される口座間の取引を時系列に記録する。ブロックチェーンはDLTの一種である。

Let’s compare a traditional Web 2.0 application with a 3.0 DApp. In Web 2.0, if you created a website for users to post pictures and make comments on them, you would need functionality for authenticating users, authorizing their actions, generating a UI for adding images, browsing images, and posting comments. To do this, you would need a front-end web server and back-end processing for business logic and data storage. These servers would run in a company’s data center or on a cloud provider. The company would own all the code and data, including metadata about how you interact with the website (e.g., what you commented on, how long you looked at a picture). As a reminder, Figure 11.4 illustrates a traditional Web 2.0 architecture (note: for our purposes, the SPA architecture could also be used here).

英語のヒント

従来型のWeb 2.0アプリケーションと、Web 3.0のDAppを比べてみよう。Web 2.0で、利用者が画像を投稿し、それにコメントを付けるWebサイトを作るなら、利用者の認証、操作の権限確認、画像の追加や閲覧、コメントの投稿を行うUIの生成といった機能が必要になる。そのためには、フロントエンドのWebサーバーと、ビジネスロジックやデータ保存を担うバックエンドの処理が必要である。これらのサーバーは、企業のデータセンターやクラウド事業者の環境で動作する。企業はすべてのコードとデータを所有し、利用者がサイトをどのように使ったかについてのメタデータも所有する。たとえば、何にコメントしたか、どれくらい長く画像を見たかといった情報である。改めて確認すると、図11.4は従来型のWeb 2.0アーキテクチャを示している。なお、ここでの目的には、SPAのアーキテクチャを使うこともできる。

In a Web 3.0 DApp, the functionality for creating an application for posting pictures and commenting on them would remain the same. The principal differences would be where the code runs and who owns the code and data. Let’s break this down into a series of steps that shift away from a centralized solution to a distributed one.

英語のヒント

Web 3.0のDAppで、画像を投稿しコメントするアプリケーションを作る場合にも、機能は同じである。主な違いは、コードがどこで動作するかと、コードやデータを誰が所有するかである。中央に集中した仕組みから分散した仕組みへの移行を、一連の手順に分けて考えてみよう。

To start, we can keep the web server’s front end and replace the back-end code with the distributed application. The Ethereum blockchain, as an example, is a deterministic state machine that runs on a peer-to-peer network. A deterministic state machine has a model of computation that relies on a finite number of states and transitions between them to respond to inputs. It guarantees a single transition from one state to another in response to an input. Because it is based on a deterministic state machine, the Ethereum blockchain is often referred to as a “world computer.” Ethereum blockchain transactions are calls to methods that are implemented in smart contracts. These method calls result in change to the data (aka, state) that is maintained by the contracts within the blockchain. The Ethereum blockchain records transactions into blocks that are added to its blockchain. Changes to the state machine itself (e.g., modify the block or transaction data structures used in the Ethereum blockchain) require consensus between the node providers that support the peer-to-peer blockchain network. Anyone in the world can read or write to the machine—a central authority does not govern it.

英語のヒント

まず、Webサーバーのフロントエンドをそのままにして、バックエンドのコードを分散アプリケーションに置き換えられる。一例として、Ethereumブロックチェーンは、ピアツーピアネットワーク上で動作する、決定性状態機械である。決定性状態機械は、有限個の状態と、それらの間の遷移に基づいて入力に応答する計算モデルを持つ。ある入力に対し、1つの状態から別の状態への遷移が1つに定まることを保証する。決定性状態機械に基づいているため、Ethereumブロックチェーンはしばしば「世界のコンピューター」と呼ばれる。Ethereumブロックチェーンの取引は、スマートコントラクトに実装されたメソッドの呼び出しである。これらのメソッド呼び出しによって、ブロックチェーン内でコントラクトが保持するデータ、すなわち状態が変化する。Ethereumブロックチェーンは、ブロックチェーンに追加されるブロックの中へ、取引を記録する。状態機械自体の変更、たとえばEthereumブロックチェーンで使うブロックや取引のデータ構造の変更には、ピアツーピアのブロックチェーンネットワークを支えるノード提供者間の合意が必要である。世界中の誰でも、この機械の読み取りや書き込みができる。中央の権限者が支配しているわけではない。

Smart contracts form the code and are written in high-level languages like Solidity or Vyper. The high-level contract code is compiled into bytecode that can be executed on the Ethereum Virtual Machine (EVM). Each block contains a hash pointer of the previous block, with a time stamp and the transaction data. The hash pointer includes a cryptographic hash (i.e., a fixed-size digest of the previous block that makes it possible to verify that the previous block was not changed since it was stored in the blockchain; the cryptographic part ensures that the hash value has some special properties and, in particular, that the original data cannot be derived from the hash value).

英語のヒント

コードを構成するのはスマートコントラクトであり、SolidityやVyperなどの高水準言語で記述する。高水準のコントラクトのコードは、Ethereum Virtual Machine（EVM）で実行できるバイトコードへコンパイルされる。各ブロックには、タイムスタンプと取引データとともに、前のブロックのハッシュポインターが含まれる。ハッシュポインターには、暗号学的ハッシュが含まれる。これは、前のブロックを一定の大きさに要約した値であり、前のブロックがブロックチェーンに保存されてから変更されていないことを検証できるようにする。暗号学的であることによって、ハッシュ値が特別な性質を持ち、特に、ハッシュ値から元のデータを導き出せないことが保証される。

Figure 11.9 replaces the traditional back-end components of a website with a blockchain. The user’s interaction with the website is consistent with a traditional Web 2.0 website, as the back-end processing is hidden from the user, though it has been replaced with a blockchain node.

図11.9では、Webサイトの従来のバックエンドの構成要素を、ブロックチェーンに置き換えている。バックエンドの処理は利用者から見えないため、ブロックチェーンのノードに置き換えられても、サイトに対する利用者の操作は、従来型のWeb 2.0サイトと同じである。

Figure 11.9 Here is a traditional Web 2.0 website with back-end components replaced with a DApp. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図11.9 バックエンドの構成要素をDAppに置き換えた、従来型のWeb 2.0サイト。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

In the figure, the web server talks to a node of the blockchain, referred to as a full node. A full node is a computer that maintains a copy of the blockchain and runs blockchain software. Operating a full node can become expensive because you need to provide the hardware and pay a fee to join the Ethereum network. Blockchain end users typically use a software wallet such as MetaMask to access nodes in the blockchain or use a third-party wallet offered by providers like Infura, Alchemy, or QuickNode. MetaMask is a wallet technology that stores a user’s private keys in their browser.

英語のヒント

図では、Webサーバーは、フルノードと呼ばれるブロックチェーンのノードと通信する。フルノードは、ブロックチェーンの複製を保持し、ブロックチェーンのソフトウェアを動かすコンピューターである。フルノードの運用は、ハードウェアを用意し、Ethereumネットワークへの参加料を支払う必要があるため、高額になることがある。ブロックチェーンの最終利用者は、通常、MetaMaskのようなソフトウェアウォレットを使ってブロックチェーンのノードにアクセスするか、Infura、Alchemy、QuickNodeなどの提供者による第三者のウォレットを使う。MetaMaskは、利用者の秘密鍵をブラウザーに保存するウォレット技術である。

Blockchain providers use the JSON-RPC specification for managing communication from clients/end users. This remote procedure call (RPC) is lightweight and transport agnostic.

英語のヒント

ブロックチェーンの提供者は、クライアントや最終利用者からの通信を管理するために、JSON-RPC仕様を使う。この遠隔手続き呼び出し（RPC）は軽量で、転送方式に依存しない。

As previously mentioned, any client can access the blockchain via a wallet provider, which requires creating an account and obtaining a wallet ID. Once logged into their wallets, clients can perform blockchain transactions, which end up reading and/or writing to the blockchain and changing the state of smart contracts. The wallet ID is used to sign transactions so they can be traced to the client wallet. In our example, browsing photos on the Web 3.0 application is a read transaction that would not require signing anything; however, adding photos and comments would.

英語のヒント

前述したように、どのクライアントもウォレット提供者を通じてブロックチェーンにアクセスできる。そのためには、アカウントを作り、ウォレットIDを取得する必要がある。ウォレットへログインすると、クライアントはブロックチェーンの取引を実行できる。この取引は、最終的にブロックチェーンを読み取り、書き込み、またはその両方を行い、スマートコントラクトの状態を変える。ウォレットIDは取引への署名に使われ、取引をクライアントのウォレットまでたどれるようにする。本書の例では、Web 3.0アプリケーションで写真を閲覧することは、何も署名しなくてよい読み取りの取引である。しかし、写真やコメントを追加する場合には署名が必要である。

Adding data to the blockchain incurs a cost as nodes now need to store that data. The user incurs this expense. Imagine paying every time you upload a photo to your favorite social media app. Instead of storing the data on the blockchain, a cost-effective approach would be to store the data using the InterPlanetary File System (IPFS) protocol. IPFS is a peer-to-peer distributed file-sharing protocol. You can go through a provider like Pinata to get a hash value for the data (i.e., a fixed length digest of the data that cannot be used to obtain the original data) you upload to the IPFS and store that hash value in the blockchain via a smart contract interface, thereby reducing the storage cost of data within the blockchain.

英語のヒント

ブロックチェーンにデータを追加すると、ノードがそのデータを保存しなければならないため、費用が発生する。この費用は利用者が負担する。お気に入りのソーシャルメディアのアプリに写真をアップロードするたびに、料金を支払うところを想像してみよう。データをブロックチェーンに保存する代わりに、InterPlanetary File System（IPFS）プロトコルで保存すれば、費用を抑えられる。IPFSは、ピアツーピアの分散ファイル共有プロトコルである。Pinataのような提供者を通じて、IPFSにアップロードしたデータのハッシュ値を取得できる。ハッシュ値は、元のデータを取り出すためには使えない、固定長の要約値である。このハッシュ値を、スマートコントラクトのインターフェースを通じてブロックチェーンに保存すれば、ブロックチェーン内でのデータ保存の費用を減らせる。

Figure 11.10 shows the addition of:

図11.10は、次のものを追加した様子を示している。

• the provider between the web server and the DApp

• WebサーバーとDAppの間の提供者。

• a signer for when the user wants to write to the application

• 利用者がアプリケーションへ書き込む際に使う署名者。

• the inclusion of the IPFS for data storage

• データ保存用のIPFS。

Figure 11.10 This architecture has added a signer, provider, and IPFS. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図11.10 署名者、提供者、IPFSを追加したアーキテクチャ。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

Up to this point, we’ve kept the front-end logic on a web server hosted in a centralized location. This is a good temporary approach for an organization that wants to transition a legacy solution to a DApp over time. Because IPFS will host some of the data of the DApp, let’s move the front-end HTML, CSS, and JavaScript there and load it into the browser like an SPA app.

英語のヒント

ここまでは、フロントエンドの処理を、中央の場所でホストされるWebサーバーに残していた。従来の仕組みを時間をかけてDAppへ移したい組織にとって、これは一時的な手法として適している。IPFSがDAppのデータの一部をホストすることになるので、フロントエンドのHTML、CSS、JavaScriptもそこへ移し、SPAのようにブラウザーへ読み込ませよう。

Like an SPA, we want the application to run asynchronously and respond to events (like changing data) as they occur. Web3.js is a JavaScript library that uses the JSON-RPC to respond to events fired when smart contracts execute. Alternatively, The Graph is a solution that uses GraphQL to make it easier to query data on the blockchain.

英語のヒント

SPAと同じように、アプリケーションを非同期に動かし、データの変更などのイベントが発生したときに応答させたい。Web3.jsは、JSON-RPCを使い、スマートコントラクトの実行時に発火するイベントに応答するJavaScriptライブラリである。別の選択肢として、The Graphは、GraphQLを使ってブロックチェーン上のデータを問い合わせやすくする仕組みである。

Figure 11.11 shows the updated architecture with the front-end residing in IPFS and the addition of The Graph (listed as GraphQL) for improved querying of the blockchain.

図11.11は、フロントエンドをIPFS内へ移し、ブロックチェーンへの問い合わせを改善するためにThe Graph（図ではGraphQLと表記）を追加したアーキテクチャを示している。

Figure 11.11 The front-end web page has been moved to IPFS, and graphing query capabilities have been added. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図11.11 フロントエンドのWebページをIPFSへ移し、グラフを用いた問い合わせ機能を追加した。（出典：Copyright Rice University, OpenStax、CC BY 4.0ライセンス）

This results in a Web 3.0 application; however, there are problems with this architecture that we will examine next.

これでWeb 3.0アプリケーションになる。しかし、このアーキテクチャには問題もあるので、次に検討する。