autorenew
Solana VMが組み込みのルーツに回帰:Memeトークン開発者が今すぐno_std Rustを学ぶべき理由

Solana VMが組み込みのルーツに回帰:Memeトークン開発者が今すぐno_std Rustを学ぶべき理由

こんにちは、ブロックチェーン好きの皆さん!Solanaとミームトークンの世界にどっぷり浸かっているなら、Anza(旧Solana Labs)の首席皮肉者ことTrentの最近のスレッドには注目しておいたほうがいいかもしれません。彼は不可解でありながら重要なアドバイスを投げかけており、今後のSolanaでの開発手法を左右する可能性があります。

事の発端は、Trentが投稿した典型的なDrakeミームで、キャプションは「retvrn to chewing glass.(ガラスを噛むに戻る)」でした。馴染みのない人向けに言うと、「chewing glass(ガラスを噛む)」は皮肉を込めた表現で、リソースが限られた組み込みシステムの粗削りな世界、つまり贅沢な機能が無い環境でのコーディングを指しています。

Drakeミーム:Rustのno_std文脈でHashMapを拒否しVecを承認する様子

そのミームでは、Drakeが「no HashMap<K, V>」を拒み「no Vec」を承認しており、no_std Rust環境でのトレードオフを茶化しているように見えます。RustではHashMapやVecはよく使われるデータ構造ですが、no_stdモード(後で説明します)では標準ライブラリが使えないため、何を使うか慎重になる必要があります。

Trentはさらに自分の投稿を引用してこう言いました:「if you're a solana program dev, learn what no_std rust is today. you will thank me tomorrow.(もしあなたがsolana programの開発者なら、今日no_std Rustが何かを学んでおけ。明日感謝するだろう)」。そして追ってもう一文を引用して付け加えました:「after a brief foray masquerading as a desktop operating system, the solana virtual machine is returning to its roots and admitting to being an embedded system.(しばしデスクトップOSのふりをしていた後、solana virtual machineはルーツに戻り、自らを組み込みシステムであると認めつつある)」

これは大きな示唆です。Solana Virtual Machine(SVM)はブロックチェーン上でスマートコントラクト(Solana用語では"programs")を動かすエンジンで、eBPF技術をベースにしています。eBPFは組み込みやカーネル環境から発祥した技術です。最近のSVMはやや「デスクトップ寄り」に振る舞っていた—つまりよりリソースを多く使える機能を許していたかもしれません—が、これからは組み込みの起源を取り入れて引き締める方向に向かっているようです。

no_std Rustとは何か?

簡単に説明しましょう。Rustは安全性と性能で知られる強力なプログラミング言語で、Solanaのプログラムを書く際の主要言語です。通常、Rustには標準ライブラリ(std)があり、ファイルI/Oやネットワーク、VecやHashMapのようなコレクションといった便利な機能を提供します。

しかし、​no_stdモードでは標準ライブラリを丸ごと使わない選択をします。なぜか? マイクロコントローラのような組み込みシステムや、今回のようなリソースが限られたブロックチェーンVMでは、標準ライブラリが前提とする環境が存在しないためです。no_stdはコードをスリムで効率的に書くことを強制し、動的メモリにはallocクレートを利用したり、独自実装を用いたりします。Solanaのプログラムはsolana-programクレート経由でデフォルトでno_stdを使っていますが、Trentのアドバイスは開発者がもっと深く理解しておくべきだという示唆であり、今後より厳密な適用や上流のeBPFとの整合性が求められる可能性を示しています。

ミームトークン制作者にとってなぜ重要か

Solana上のミームトークンは大流行中です――素早いローンチ、バイラルなポンプ、コミュニティ主導の盛り上がりなどを想像してください。ほとんどは標準のSPL Tokenプログラムを使いますが、高度なトークノミクス、ローンチパッド、統合型DEX機能などのカスタムロジックを組み込む場合はSolanaプログラムを書く必要があります。

SVMが「ルーツに回帰」するならば、組み込み風のコーディングをより求められる変更が出てくるかもしれません。具体的には以下のようなことが考えられます:

  • 厳しいリソース制限:プログラムはさらに最適化が必要になり、重いデータ構造を避けてcompute unit(Solanaのガス相当)消費を抑える必要が出るかもしれません。

  • 上流のeBPFとの互換性向上:Dean Littleの「upstream eBPFに戻す」という返信のように、Solanaがより広い組み込み技術に合わせることで堅牢になる一方、no_stdの習熟が必須になる可能性があります。

  • ミームの将来耐性:ミーム領域の開発者が今のうちにno_stdを学んでおけば、アップデートが来たときにスムーズに対応できます。返信ではPinocchiansのようなツールが既に講座を準備しているといった話も出ていました。

@japarjamのJeffによる返信のひとつは、彼のチームがこれを業務に組み込んでいることを示しており、コミュニティがQ4の変更に向けて準備を進めている兆候です。

no_std Rustの始め方

始める準備はいいですか?簡単なガイドをどうぞ:

  • ドキュメントを読む:まずはRust no_std guideで基本を学びましょう。

  • サンプルで練習する:基本的なアロケータを作る、coreライブラリの機能を使うなど、no_stdで動く簡単なクレートから始めてみてください。

  • Solana固有のリソース:まずはSolana Program Libraryを調べ、solana-programクレートをno_std設定で試してみましょう。

  • コミュニティツール:SVMはeBPFベースなので、eBPFの資料もチェックしましょう。また、この舵を取っているAnzaのアップデートにも注目してください。

この変化はSolanaをさらに高速かつ効率的にし、ミームトークン取引の高スループット需要にマッチする可能性があります。ただし、それは開発者が基礎を怠れないことも意味します。

みなさんはどう思いますか?ルーツへの歓迎すべき回帰でしょうか、それとも開発者にとって頭の痛い変更でしょうか?コメントで教えてください。今後もMeme Insiderでは、ブロックチェーンの微調整があなたのお気に入りのミームにどう影響するかを追っていきます。

スレッド全体はこちらでご覧ください。

おすすめ記事