今週のざっくばらん
中学生にも分かるWeb3-9(メルマガ限定)
Solidity のメソッド
Solidity には他の言語と違ういくつかの特徴がありますが、もっとも際立っているのは関数のmutabilityです。"view" という属性は、データを読むことしかせず書き込みをしないこと、"pure" という属性は、データを読みも書きもしないことをしめし、それ以外はデータの書き込みと読み込みの両方をすることを示します。
Swift(iOS/macOS用のプログラミング言語)にも似た様なものがありますが(struct の function に mutating という属性を付けることが可能)、実行の仕方にとんでもない違いがあるのです。
"view" や "pure" の属性を持つ関数は、アプリケーションがProxy(ブロックチェーンとの接続をしてくれるサーバー)を通じて接続したマシンのみで実行されますが、そうでない書き込み属性を持つ関数は、ブロックチェーンを構成する全ての(Ethereum の場合だと100万台近くある)マシンで実行されるのです。
とんでもない無駄の様に感じるかも知れませんが、これが今のブロックチェーンの設計であり、それをするからこそ、全てのマシンの状態を同じに保てるし、少数派による攻撃にも耐えられるのです。
それゆえ、書き込み属性を持つ関数を呼び出す際には、計算量に応じた「ガス代」がかかるので、Solidityでプログラミングする際には、そこに注意を払う必要があります。
それもあって、私が On-Chain AssetStore を開発する際には、徹底的にガス代にこだわった設計をし、ベクトルデータをブロックチェーン上に書き込む時のガス代を極力下げるように注意を払いました。
逆に、データをブロックチェーンから読み込む際には、ガス代がかからないので、「富豪プログラミング」とまでは言いませんが、気楽にコードを書いてリリースしました。
しかし、家紋NFTをローンチする段階になって、テスト中にブロックチェーンからのデータの読み込みに失敗するケースに遭遇し、読み込みの際にも、ガス代はかからないものの、計算量には制限があることを発見しました。
いまだに、その制限の明確な定義を見つけることは出来ませんが、計算量が2000万ユニットを超えたあたりからエラーになるケースが増えるようです。
問題は、圧縮してしまったベクトルデータをSVGデータとして取り出す部分の実装にありましたが、幸いなことにそこは、メインのスマートコントラクト(AssetStore)から切り離して、アップグレード可能な別のスマートコントラクト(SVGPathDecoder)で実装していたので、そこをより効率の良いソフトウェアに置き換えることにより対処出来ました。
Full On-Chain と decentralization
最近、「私はNFTはFull On-Chainであるべき」という信念の元に、スマートコントラクトで動的にベクトルデータを生成するPride Squiggle や、ブロックチェーン上に誰でもアクセス可能なベクトル・データのレポジトリを作る On-chain AssetStore などを開発しています。
「Full On-Chain なNFT」とは、NFTを構成する要素全てがブロックチェーン上にあり、ブロックチェーン以外のサービスに依存していないことを示します。
現時点で、NFTの大半は Full On-Chain ではありません。NFTにおいて最も重要である「画像を含むメタデータ」をブロックチェーンの外側に置いているからです。
NFTの共通仕様であるERC-721 には、tokenURI というメソッドが定義されており(厳密にはオプションであるERC721Metadata に定義されているメソッドですが、これが実装されていなければ、OpenSeaなどで表示すらできないので、実質的にはオプションではありません)、OpenSea などのサービスは、このメソッド取得したURI(インターネット上の識別子)から取得したメタデータ(name, description, image)を使ってNFTを表示します。
ほとんどのNFTは、URIとして"https:"で始まるインターネット上のデータ、もしくは"ipfs:"で始まるIPFS(InterPlanetary File System)上のデータを返すように実装されています。
インターネット上のデータとは、つまり、AmazonやMicrosoftが提供するクラウドサービスに依存したものであり、Web3のコアコンセプトであるdecentralizedとは根本的に矛盾する話です。このURIは、NFTを提供している事業者が、そのクラウドサービスを提供しているAmazonやMicrosoftに月額使用料を支払い続けないかぎり無効になってしまうURIであり、永続性は全く保証されないのです。
IPFSは、P2Pなストレージサービスなので、一般のクラウドサービスよりは分散化されたものですが、それでも、データの存在を保持するためには、NFTを提供する事業者がそのデータをPINし続ける(IPFSノードを立ててそのデータを保持し続けること)必要があり、こちらも永続性は保証されていないのです。
NFTの永続性を保証する唯一の方法は、URIそのものに必要なメタデータが埋め込まれている"data:"で始まるURIを返すことで、それをして初めて、NFTの永続性が保証されるのです。
つまり、画像も含めたNFTのメタデータ全てをURIの中に埋め込むことができるかどうか(NFTがブロックチェーン上のデータだけで完結しているかどうか)が、NFTの永続性と直接関わってくるのです。
Axie InfinitiやSTEPNに代表されるPlay2Earn系ゲームの支持者が、「入手したNFTはサービスとは独立して永遠にユーザーのもの」と主張することがありますが、これは全くの出鱈目です。ゲーム提供者がサービスを停止し、メタデータを保持しているクラウドサービスへの支払いを停止したり、IPFSのデータのPINを停止すれば、画像を含めたNFTのメタデータは、この世の中から消えてしまうのです。
私がDAOに参加し、NFTのコントラクトを読み込んだ Nouns は、NFTの中では珍しく Full On-chain なNFTであり、NFTの永続性は保証されています。つまり、Nounders と呼ばれるNounsの創業者たちが、たとえNounsDAOから離れてしまっても、NounsNFTは永遠に存在し続けるのです。
そう考えると、画像も含めたNFTのメタデータを全てブロックチェーン上に置くことはとても重要であることは明確です。
にも関わらず、大半のNFTがメタデータをブロックチェーンの外に置いているのは、大きな画像をブロックチェーン上のセーブするのに必要な高いガス代であり、そのため、Full On-ChainなNFTは、Nounsのようにデータ量の少ないピクセル画像に限定されているのです。
そこでまず試しに作ったのがスマートコントラクトのロジックを使ってベクトル画像を生成する Pride Squiggle です。この領域は「generative art」と呼ばれ(下はGoogleでの検索結果)、GPUプログラマーの間では盛んに行われていますが、Solidityではまだまだで、作品もほとんど見つけることが出来ません。
そもそも Solidity を使いこなせるエンジニアが少ない上に、現時点のWeb3のビジネスを支配するDeFiとGameFi(Play2Earnゲーム)ビジネスがSolidityエンジニアを高給で雇ってしまうため、こんな遊びごころに溢れたプログラミングをする余裕がないのだと思います。
しかし、Web3プログラミングに夢中になりながらもDeFi/GameFi業界で働く気がしない私にとっては、これは絶好のブルーオーシャン(ライバルのいない領域)であり、思いっきりクリエイティビティを発揮するチャンスなのです。
とは言え、generative artにも限度があり、やはりプロのアーティストが作った画像を効率よくブロックチェーンで活用する技術の開発は必須であり、そこで開発しているのがOn-Chain AssetStoreです。
この記事は約
NaN 分で読めます(
NaN 文字 / 画像
NaN
枚)