- Go back to TOP(インデックスページへ)
- Flow account model
- Account
- Resources
- Capability-based access
- Contract standards
Cadenceは、Solidity開発者にとっては馴染みのないスマートコントラクト開発のアプローチを紹介します。根本的な考え方やプラットフォームの違いがあり、またSolidityには実質的な同等機能がない新しい言語機能もいくつかあります。
このガイドでは、理解しておくべきFlowとCadenceのハイレベルな設計と概念的な側面、プラットフォームと統合の違い、およびCadenceのイディオムを使用して特定の一般的なSolidity開発タスクを実行する方法の詳細なガイダンスについて概説します。また、Cadence独自の機能の最適な活用方法と、移行中に発生する可能性のある一般的な問題を回避する方法についても詳しく説明します。
Conceptual foundations for Cadence
SolidityからCadenceに慣れる際に慣れるべき根本的な違いは、考え方です。Ethereumのセキュリティと相互運用性はアドレス（より正確にはアドレスに関連付けられたアカウント）を中心に設計されているため、すべてのコントラクトはアクセスと承認を慎重に追跡し評価する必要があります。
トランザクションは、誰が承認したかによって決定され、その情報はトランザクションのコンテキストでmsg.senderとして提供されます。ユーザーとコントラクト、またはコントラクトとコントラクトのやり取りは、コントラクトとやり取りを行う前に適切な承認が行われたことを保証するために、明示的にコード化する必要があります。ストレージがコントラクトベースであることから、Ethereumにおけるユーザーの所有権は、例えば所有者から残高、またはトークンIDから所有者に至るマッピングで表されます。言い換えれば、所有権は個人の銀行残高と同様に、台帳の記録で追跡されます。 暗号ウォレットは、複数のトークンタイプの残高をユーザーにとって便利な形で統合するのに役立ちます。
Cadenceは、Flowのアカウントモデルを基に設計された、新しいプリミティブと明確な機能、すなわちリソースと機能性を導入します。 リソースは、一意でコピー不可能であり、破棄できない、言語の第一級型です。これらの特性により、リソースは、通貨やトークンなどの常に数が限られているデジタル資産を表すのに最適です。リソースは常にアカウントストレージに格納され、コントラクトは機能を使用してそれらへのアクセスを制御します。機能は、アドレスを追跡する必要なくリソースを保護するもう一つの特別なタイプです。Cadenceは、オブジェクト指向のプログラミング言語に精通している人にとっては、これらの作業を簡単かつ直感的に行えるようにします。
Cadenceを初めて使用する方は、開発前に以下の主要な概念を理解しておく必要があります。
Flow account model
CadenceのFlowアカウントモデルでは、アカウントに関連付けられたキーとコード（「スマートコントラクト」）のストレージと、そのアカウントが所有するアセットのストレージが組み合わされています。 そうです、Cadenceでは、トークンはスマートコントラクトではなく、アカウントに保存されます。 もちろん、スマートコントラクトはこれらのアセットとそれらの動作を定義しますが、それらのアセットはリソースのマジックにより、ユーザーのアカウントに安全に保存することができます。 Cadenceにはアカウントの種類は1つしかなく、アカウントのアドレスも存在します。これは、イーサリアムの外部所有アカウント（EOA）アドレスに似ています。ただし、イーサリアムのコントラクトアカウントとは異なり、Cadenceのアカウントにはコントラクトコードも保存されます。アカウントは、チェーン上にキー、リソース、コントラクトが保存されるコンテナであるため、Flowの所有権を実現します。Account
Accountは、アカウントへのアクセスを提供するタイプです。
getAccount関数は、アカウントの公開されている関数やフィールドへのアクセスを許可します。例えば、これによりアカウントの残高照会が可能になります。
認証済みのAccount参照は、アクセスを許可し、例えばアカウントのストレージ、キーのコンフィグレーション、コントラクトコードの管理を可能にします。認証済みのAccount参照は、トランザクションに署名することで取得できます。機能により、アカウントに保持されているリソースを安全に共有/アクセスできるようになります。
Resources
リソースは、アカウント間で移動させることはできても、コピーや暗黙的な破棄は決してできないユニークなLinear Typesです。開発中に、関数スコープでアカウントから取得したリソースを関数に保存できなかった場合、意味論的なチェックによりエラーが通知されます。実行時にも、許可された操作に関して同様の厳格なルールが適用されます。したがって、終了前にスコープ内のリソースを適切に処理しないスマートコントラクト関数は中断され、元の保存状態に戻されます。リソースのこれらの機能により、交換可能なトークンと交換不可能なトークンの両方を表現するのに最適です。トークンの所有権は、トークンが保存されている場所によって追跡され、言語自体が正確性を強制するため、資産が重複したり、誤って失われたりすることはありません。
Flowは、データの保存とオンチェーンでの計算を促進し、リソース型はこれをこれまで以上に容易にします。リソースは常にアカウントに保存されているため、リソースインスタンスに存在するデータやコードは、明示的な処理を必要とすることなく、シームレスにオンチェーンで管理されます。
Capability-based access
保存されたオブジェクトへのリモートアクセスは、Capabilitiesを介して管理することができます。つまり、あるアカウントが他のアカウントの保存されたオブジェクトにアクセスできるようにしたい場合、そのオブジェクトに対して有効なCapabilityが提供されていなければなりません。Capabilityは、公開または非公開にすることができます。アカウントは、他のすべてのアカウントにアクセス権を与えたい場合、PublicCapabilityを共有することができます。（例えば、アカウントがPublicCapabilityを介して、あらゆるソースから代替可能なトークン預金を受理することは一般的です。） あるいは、アカウントは特定のアカウントにPrivateCapabilityを提供することで、(一般には)制限されたCapabilityへのアクセスを許可することができます。例えば、NFTプロジェクトでは、特定のアカウントに新しいトークンを発行する権限を与える「administrator Capability」を通じて、トークンの発行を管理することがよくあります。
Contract standards
エコシステムに利益をもたらすために、広く使用されている多数のContract Standardsが策定されています。例えば、EthereumのERC-20およびERC-721標準と概念的に同等であるFungible Token（FT）およびNon-Fungible Token（NFT）標準などがあります。Cadenceのオブジェクト指向設計では、リソース、リソースインターフェース、または契約標準で宣言されたその他のタイプなどの契約サブタイプを通じて標準が適用されます。標準は、動作を定義および制限し、標準の実装が違反できない条件を設定することができます。
利用可能な標準およびその他のコア契約に関する詳細情報は、「Introduction to Flow」をご覧ください。
（他にもあります。詳しくは翻訳元の原文へ）
翻訳元->https://cadence-lang.org/docs/solidity-to-cadence