リソース指向はブロックチェーン・プログラミングの品質を上げる
Flow で使われている Cadence 言語のもっとも大きな特徴は、リソース指向プログラミングという新しい考え方です。この記事では、リソース指向とは一体どういうもので、どういう利点があるのかを解説します。
リソースは新しい所有モデル
現在、ブロックチェーンでアイテムの所有権を示す場合、「誰が何のアイテムを持っているか」を中央台帳で管理するのが一般的です。
しかしこの方法には、所有権の書き換えミスやアイテムの誤削除が発生しうるという潜在的な課題があります。これを防ぐには、入念なコードレビューと監査が欠かせず、多大なコストがかかります。
一方、Cadence における所有権は、「そのアイテムがどこに存在しているか」という構造で管理されます。このために使われるのが、「リソース」と呼ばれる特別なオブジェクトです。各アカウントには、自分しかアクセスできない個別のストレージが用意されており、そこにリソースを格納できます。
リソースを使うことで NFT の管理がより安全に
Cadence 言語が持つルールとして、リソースは複製ができず、リソースの操作はそれを持つアカウントに制限されます。
実際にコードを書いてみるとわかるのですが、このルールによりかなり厳しくコンパイルエラーが出ます。一見問題がないようにみえて潜在バグがあるコードに比べると、コーディング時点でセキュアな実装が保証されていることは素晴らしいです。
Cadence でリソースを扱うコードを書いていたとき、私は、初めて Java 言語を使ってコードを書いたときのことを思い出しました。C 言語では自分でメモリを管理しなければなりませんが、高級な言語ではそれは不要です（気にしなくて良いわけではありませんが）。誰がどのアイテムを持っているか台帳で管理することは、メモリを管理することに似ており、リソース指向ではこれは不要となります。
現在はまだ、サービスが立ち上がったばかりで、プロダクションレベルで定石といえる開発手法が決まっていませんが、将来的には Ethereum よりも低コストでセキュアなスマートコントラクトがかけるようになるのではないかと考えています。
アクセス管理の簡素化は「コンポーザビリティ」を向上させる
よくブロックチェーン・プログラミングの話で「コンポーザビリティ」という言葉が出てきます。Ethereum では、あるスマートコントラクトと別のスマートコントラクトを組み合わせて、新しいものを作ることができます。このとき重要になるのがコンポーザビリティ、つまり、いかに組み合わせやすく作られているか、という点です
Solidity では、誰が NFT を操作できるかという制御はすべてコードに書く必要があります。これは別のスマートコントラクトからのアクセスを難しくします。例えば、Ethereum の NFT を別コントラクトから呼び出す場合、NFT の所有者が実行していたとしても、通常、別コントラクト経由で NFT を移動させることはできません。これを実現するには、あらかじめ元のコントラクトに特別なアクセス管理の機能を入れておき、NFT の所有者は追加の操作を行う必要があります。
一方、Cadence の所有モデルでは、そのリソースが どのアカウントのストレージに置かれているか で所有者が決まり、そして所有者はそのリソースを自由に操作することができます。これは言語のルールとして決まっているため、アクセス制御のコードを書く必要がありません。この特徴は明らかにコンポーザビリティを向上させます。
昨年実施された Cadence Cup では「リソースを所有するリソース」という課題がありました。私はこのとき、NFT を鍵付きのケースに入れて、他の人に安全に貸せるコントラクトを実装したのですが、これを実現するために元の NFT のコードを変更する必要は一切ありませんでした。
このような既存コントラクトの拡張が、Flow ではセキュアかつ簡単に実現できます。
是非、チュートリアルでリソース指向プログラムを体験してください
公式サイトの Cadence チュートリアルはとても充実しており、Cadence のイロハを順を追って学べます。プレイグラウンドと呼ばれる、ブラウザだけでコードを実行できる環境は素晴らしいです。
Cadence を理解するには、これまでの考え方をリセットして頭を切り替える必要がありますが、チュートリアルで用意されている内容はひとつひとつが面白いので、楽しみながら学習することができます。
コミュニティで日本語の翻訳も作りましたので、是非ご参照ください。
