オリジナルの独自コントラクトとthirdwebの独自コントラクトを比較

今回は、ちょこちょこ聞かれるので、オリジナルの独自コントラクトとthirdwebの独自コントラクトを比較してみました。

個人的な意見になっていますので、鵜吞みにするのではなく参考程度に捉えてくださいね

※独自コントラクトもthirdwebも独自コントラクトです。ここでは、オリジナルの独自コントラクトを独自コントラクト、thirdwebのproxyコントラクトをthirdwebとします。

コントラクトの違い

thirdwebのコントラクトは、通常のコントラクトとは異なり、Proxyコントラクトと呼ばれるものになります。

Proxyコントラクトについて（概要）

様々な種類があるのですが、別のコントラクトの機能なりデータなりを利用しているコントラクトになります。

Proxyコントラクトを利用する際は、アップグレード機能を盛り込むことが多いです。

ロジックを担っているコントラクト側に、アップグレード機能がある場合、ロジックをアップグレードできます。

Proxyコントラクトは、ロジックコントラクトの機能を利用しているだけなので、必然的にアップグレードの影響を受けます。

例えば、今Proxyコントラクトにて、mint機能を使うとNFTが発行できるとします。

この場合、Proxyコントラクトにmint機能があるのではなく、ロジックコントラクトのmint機能を使っています。

ロジックコントラクト側で、mint機能の中身を、「NFTの発行」から「あるアドレスに送金」だけする機能にアップグレードするとします。

すると、Proxyコントラクトにてmint機能を実行すると「あるアドレスに送金」されてしまいます。

また、コントラクトを破棄する機能も存在します。

仮にロジックコントラクトを破棄した場合、Proxyコントラクトは使えなくなります。

とはいえ、Proxyコントラクトからロジックコントラクトの参照先の変更は、Proxyコントラクト側にあります。

無理やり結びつけることは可能なんだろうなぁ・・・と思いながら・・・。

当然メリットもたくさんあるのですが、一般的なNFTプロジェクトに的を当てると、ガス代がとにかく安いことだと思います。

まったく同じ機能を持たせた場合、独自コントラクトに比べてコントラクト発行にかかるガス代は、90%以上抑えることが出来ます。

まとめると

Proxyパターン自体は、ブロックチェーンの多くの問題を解決するためには必要不可欠な技術です。

多くの場合、アップグレード機能を採用するため、ブロックチェーンのイメージと相反する側面を持ちます。

Proxyコントラクトがダメということではなく、発行元が信頼できるかどうかだと思います。

なので、私個人の意見としては、そこまで気にする必要ないのでは？と思ってます。むしろガス代の方が問題！！

コントラクトの脆弱性について

独自コントラクトの大きな問題は、コントラクトの脆弱性の検証不足に陥りやすい点だと思います。

無茶苦茶優秀な開発者であれば、多くの知見による優れたテストが出来ると思います。

それでもやはり色んな角度からのテストを実施するのは、なかなか難しいと思うんです。

NFTプロジェクトにおいては、少人数でのチームも多く、複数の開発者で検証できていないプロジェクトが多いと思います。

経験豊富な開発者ですら、意外なテスト漏れがあり、プロジェクトに問題が発生したりしています。

一方、thirdwebは、複数人による監査も実行しているし、バグを見つけると報奨金がでる「bug bounty program」を採用しています。

コントラクトの脆弱性の検証においては、はるかにthirdwebコントラクトの方が検証されていると考えられます。

サポート面について

これも上記に絡んでくることですが、携わる人間が少ないプロジェクトだと個々人に何か起きた時に頓挫してしまいます。

そういった意味では、独自コントラクトを依頼する場合は、かなりのリスクを背負っていると考えた方が良いと思います。

予期せぬことを想定して引継ぎができるような形でプロジェクトをまとめていけば多少リスクが低減できるかと思いますが、それはそれでかなりの負担が想定されます。

一方で、thirdwebを利用する場合は、discordから問い合わせが出来るし、凄く丁寧に対応してくれます。

また、共用のダッシュボードでプロジェクトを管理することが出来るので、引継ぎなどもしやすいです。

スピード感

独自コントラクトに盛り込む内容にもよりますが、コントラクト作る⇒テストを作る⇒テストして修正するのサイクルを回すので、それなりに時間がかかります。

一方で、thirdwebを利用する場合は、コントラクト部分については完成されているので、そこに時間を割く必要はありません。

thirdwebの方が良い？

ここまで読んでもらった通り、独自コントラクトに比べると、一般的なプロジェクトであれば、thirdwebの方が遥かに優位だと思っています。

一方で、下記のケースに該当する場合は、独自コントラクト採用になるかと思います。

metadataやメディアデータの管理をarweaveで行いたい

thirdwebでは、metadataやメディアデータは、ipfsサーバーで保管しています。

個人的には、thirdwebだけに管理を任すのではなく、プロジェクトの管理者がピン付けをするor購入者がピン付けをする必要があると思っています。

一方で、様々な理由によりipfsサーバーではなくarweaveサーバーで保管したいとします。

• 現状では、thirdwebではarewaveに対応しておりません。（近日対応予定）
• metadataを参照しているbaseURIを変更することが出来ません。

そのため、thirdwebを利用する場合は、ipfsサーバーでの管理が必要になってきます。

※メディアデータのみarweaveにすることは可能

一方で、baseURIやmetadata自体、そもそも変更できるべきではないと考える人も多く、変更できないプロジェクトが多々あります。

特殊な機能を追加したい

thirdwebが提供するコントラクトには、特殊な機能を備えたコントラクトも多数あります。

しかし、提供されている機能しか使うことができないので、かなり特殊な機能を付け加えたい場合には、独自コントラクトを選ぶしか選択肢はありません。

それ以外にも、例えばコントラクトに模様を埋め込みたいなどオリジナルにこだわる人は、独自コントラクトを選ぶことになるかと思います。