今回は、アクセス制限を行うスマートコントラクトの動作確認を行います。
アカウントごとの役割
アカウントの役割は次の通りです。
- MAIN ACCOUNT (eth.accounts[0]) “0xec3b01f36b44182746ca109230567c4915512e35”
コンストラクトの生成者。初期オーナー - ACCOUNT1 (eth.accounts[1]) “0x63f25b9bbd974fdfa07477cb99c60d2073cfe560”
２番目のオーナー - ACCOUNT2 (eth.accounts[2]) “0xd5adf1e9fbc1ed869ed4c7372961238fddc760a5”
マイナー。
デプロイ
まずはデプロイを行います。デプロイアカウントはMAIN ACCOUNTです。
デプロイするコントラクトは、Ownedコントラクトを継承したAccess Restrictionコントラクトになります。
[デプロイ時のイメージ]
デプロイ後のコントラクトの状態を確認します。
[コントラクトの状態]
オーナーがMAIN ACCOUNTで、ステートがinitialであることが確認できます。
オーナーアドレスからステート更新
オーナーのMAIN ACCOUNTから、ステートを更新します。(Update State関数)
ステートはowenerです・・・スペリングを間違えました😥
[ステート更新]
コントラクトの状態を確認します。
[コントラクトの状態]
ステートがinitialからowenerに変わっています。
アクセス権のないアドレスから更新
オーナーではないAccount1からステートを変更してみます。
ステートはnot ownerを設定してみました。
また最大消費手数料としては5,000,000 weiを指定しました。(EXECUTEボタン押下後のダイアログ画面にて)
[ステート更新]
コントラクトの状態を確認します。
[コントラクトの状態]
ステートが変わらずowenerであることが確認できます。
念のためトランザクションの内容も確認します。
[トランザクションの結果]
Gas Usedが5,000,000 weiとなっており、手数料が最大で消費されているのでこのトランザクションが失敗したことを再確認できます。
オーナー変更
コントラクトのオーナーを変更します。（MAIN ACCOUNT ⇒ Account1）
Change Owner関数を選んで、new ownerにはAccount1のアドレスを入力します。
この処理はアクセス制限によりオーナーのみが実行できるので、Execute fromにはMAIN ACCOUNTを指定します。
[オーナー変更]
コントラクトの状態を確認します。
[コントラクトの状態]
ちゃんとオーナーがAccount1に変更されています。
２番目のオーナーからステート更新
オーナーがAccount1に変更されてたので、Account 1からステート変更を行えるかどうか確認します。
Update State関数を選択し、new stateにnew ownerを入力します。
Execute fromはもちろんAccount1です。
[ステート更新]
コントラクトの状態を確認します。
[コントラクトの状態]
ステートがnew ownerに変更できています。
以上で、アクセス制限のあるコントラクトの動作確認は完了です。
アクセス制限のポイント
関数をpublicで公開することは攻撃表面（リスク）を大きくするので、公開は最小限にするべきです。
また特定のアドレスのみが利用する関数については、必ずアドレスによるアクセス制限を付与しましょう。
アクセス制限のポイントをまとめます。
- アクセス制限はmodifierにて実装する。
- 可能な限り関数は公開しない。
- 特定のアドレスからの呼び出しを想定している関数は、必ずアドレスによる制限を設ける。
- オーナー変更用の関数を用意する。
- ひな形化しておき継承してコントラクトを作成する。