小学生でも理解できる!Solanaのプログラミングモデルは、ETHと何が違うのか?
執筆: Foresight News , Alex Liu
Solana は dApps をサポートすることを目的とした高性能のブロックチェーンプラットフォームであり、その速度とスケーラビリティで知られています。これは独自のコンセンサス機構とアーキテクチャ設計によって実現されています。本稿では、Ethereum を比較対象として、Solana のスマートコントラクトプログラミングモデルの特徴を簡潔に紹介します。
スマートコントラクト、オンチェーンプログラム:
Ethereum 上で動作するプログラムはスマートコントラクトと呼ばれ、Ethereum 上の特定のアドレスに存在する一連のコード(関数)とデータ(状態)です。(おっと、コードとデータが結合しています)スマートコントラクトは Ethereum アカウントでもあり、コントラクトアカウントと呼ばれ、残高を持ち、取引の対象となることができますが、人間が操作することはできず、ネットワーク上にプログラムとしてデプロイされて実行されます。
一方、Solana 上で実行される実行可能なコードはオンチェーンプログラム(On-chain Program)と呼ばれ、各取引で送信される命令を解釈します。これらのプログラムは、ネットワークのコアにネイティブプログラムとして直接デプロイすることも、誰でも SPL プログラムとして公開することもできます。
- 命令 (Instructions):命令は Solana のオンチェーンプログラムの特有の用語です。オンチェーンプログラムは命令で構成され、特定の操作を実行するための最小単位です:各 Solana 取引には1つ以上の命令が含まれています。命令は実行する操作を指定し、特定のオンチェーンプログラムを呼び出したり、アカウントを渡したり、入力リストを提供したり、バイト配列を提供したりします。命令には計算制限があるため、オンチェーンプログラムは少量の計算ユニットを使用するように最適化されるべきであり、高価な操作は複数の命令に分割する必要があります。
- ネイティブプログラム :検証ノードに必要な機能を提供するネイティブプログラムです。その中で最も有名なのは System Program で、新しいアカウントの作成や2つのアカウント間での SOL の転送を管理します。
- SPL プログラム :トークンの作成、交換、貸し出し、ステーキングプールの作成、オンチェーンドメイン名解決サービスの維持など、一連のオンチェーン活動を定義します。その中で、SPL Token Program はトークン操作に使用され、Associated Token Account Program などは他のカスタムプログラムの作成に一般的に使用されます。
あなたはスマートコントラクトと呼び、私はオンチェーンプログラムと呼びます。言い方は異なりますが、どちらもブロックチェーン上で実行されるコードを指しています。張三、李四、王麻子は人名ですが、結局のところ、素質は他の側面で評価する必要があります。
アカウントモデル、データのデカップリング:
Ethereum と同様に、Solana もアカウントモデルに基づくブロックチェーンですが、Solana は Ethereum とは異なるアカウントモデルを提供し、異なる方法でデータを保存します。
Solana では、アカウントはウォレット情報やその他のデータを保存でき、アカウントが定義するフィールドには Lamports(アカウント残高)、Owner(アカウント所有者)、Executable(実行可能アカウントかどうか)、Data(アカウントが保存するデータ)が含まれます。各アカウントは、どのプログラムの状態ストレージとして使用されるかを区別するために、プログラムを所有者として指定します。これらのオンチェーンプログラムは読み取り専用または無状態であり、プログラムアカウント(実行可能アカウント)は BPF バイトコードのみを保存し、状態は他の独立したアカウント(非実行可能アカウント)に保存されます。つまり、Solana のプログラミングモデルはコードとデータをデカップリングしています。
一方、Ethereum アカウントは主に EVM 状態の参照であり、そのスマートコントラクトはコードロジックを持ち、ユーザーデータを保存する必要があります。これは通常、EVM の歴史的な設計欠陥と見なされています。
この違いを軽視してはいけません! Solana のスマートコントラクトは、結合されたプログラミングモデルを持つブロックチェーン(例えば Ethereum)よりも根本的に攻撃が難しいです:
Ethereum では、スマートコントラクトの「所有者」はグローバル変数であり、スマートコントラクトと一対一で対応しています。したがって、特定の関数を呼び出すことは、コントラクトの「所有者」を直接変更する可能性があります。
一方、Solana では、スマートコントラクトの「所有者」はアカウントに関連付けられたデータであり、グローバル変数ではありません。1つのアカウントには複数の所有者が存在することができ、一対一の関連付けではありません。攻撃者がスマートコントラクトのセキュリティ脆弱性を利用するには、問題のある関数を見つけるだけでなく、その関数を呼び出すための「正しい」アカウントを準備する必要があります。このステップは容易ではなく、Solana のスマートコントラクトは通常、複数の入力アカウントを含み、制約条件(例えば ` account1 . owner == account2 . key ` )を通じてそれらの関係を管理します。「正しいアカウントを準備する」から「攻撃を開始する」までのプロセスは、セキュリティ監視者が攻撃前にスマートコントラクトに関連する「偽の」アカウントの作成に関する疑わしい取引を積極的に検出できるようにするのに十分です。
Ethereum のスマートコントラクトは、唯一のパスワードを使用する金庫のようなもので、そのパスワードを手に入れれば完全な所有権を得ることができます。一方、Solana のスマートコントラクトは多くのパスワードを持つ金庫のようなもので、権限を取得するには、パスワードを手に入れるだけでなく、そのパスワードに対応する番号を理解する必要があります。
プログラミング言語
Rust は Solana 上でスマートコントラクトを開発するための主要なプログラミング言語です。その性能と安全性の特性により、ブロックチェーンやスマートコントラクトの高リスク環境に適しています。Solana は C、C++ およびその他の言語(あまり一般的ではありません)もサポートしています。公式には Rust と C の SDK が提供され、オンチェーンプログラムの開発をサポートしています。開発者はツールを使用してプログラムを Berkley Packet Filter (BPF) バイトコード(ファイル拡張子は .so)にコンパイルし、Solana チェーンにデプロイして、Sealevel 並列スマートコントラクト実行環境を通じてスマートコントラクトのロジックを実行します。
Rust 言語は習得が難しく、ブロックチェーン開発向けに特化されていないため、多くのニーズに対して再利用やコードの冗長性が発生しています。(多くのプロジェクトは、Backpack の共同創設者である Armani によって作成された Anchor フレームワークを使用して開発を簡素化しています)ブロックチェーン開発専用に新たに創造された多くのプログラミング言語は Rust に基づいており、Cairo(Starknet)、Move(Sui、Aptos)などがあります。
多くのプロジェクトが Anchor フレームワークを採用しています。
Ethereum のスマートコントラクトは主に Solidity 言語で開発されています(構文は JavaScript に似ており、コードファイルの拡張子は .sol です)。構文が比較的簡単で、開発ツールがより成熟している(Hardhat フレームワーク、Remix IDE …)ため、通常、Ethereum の開発体験はより簡単で快適であると考えられていますが、Solana の開発は習得が難しいです。そのため、現在 Solana の人気は高いものの、実際には Ethereum の開発者数は Solana よりもはるかに多いです。
特定の道路状況下では、トップレベルのレーシングカーは改造車よりも速く走ることができません。Rust はトップレベルのレーシングカーのように、Solana の性能と安全性を力強く保証しますが、オンチェーンプログラム開発のために生まれたわけではなく、逆に運転(開発)の難易度を上昇させています。Rust に基づき、オンチェーン開発向けに特化した言語を採用する公的ブロックチェーンは、このレーシングカーを改造し、より道路状況に適応させることに相当します。この点で Solana は劣位にあります。
まとめ
Solana のスマートコントラクトプログラミングモデルは革新的です。無状態のスマートコントラクト開発方法を提供し、Rust を主要なプログラミング言語として採用し、ロジックと状態を分離するアーキテクチャを持つことで、開発者がスマートコントラクトを構築しデプロイするための強力な環境を提供し、安全性と性能を確保しますが、開発の難易度は高いです。Solana は高スループット、低コスト、スケーラビリティに焦点を当てており、高性能な dApps を作成しようとする開発者にとって、現在の理想的な選択肢です。