オークション用のコントラクトを実行していきます。
アカウントごとの役割
アカウントの役割は次の通りです。
- MAIN ACCOUNT (eth.accounts[0]) “0xec3b01f36b44182746ca109230567c4915512e35”
オークションの オーナー。 - ACCOUNT1 (eth.accounts[1]) “0x63f25b9bbd974fdfa07477cb99c60d2073cfe560”
Bidder1(入札者1)。アカウント1。 - ACCOUNT2 (eth.accounts[2]) “0xd5adf1e9fbc1ed869ed4c7372961238fddc760a5”
Bidder2(入札者2)。アカウント2。 - ACCOUNT3 (eth.accounts[3])
マイナー
デプロイ
まずはデプロイを行います。デプロイアカウントはMAIN ACCOUNTです。
[デプロイ時のイメージ]
デプロイ直後のコンストラクトの状態を確認します。
[コンストラクトの状態]
- コンストラクトの残高確認
0 ether - 最高提示者のアドレス確認
Main account - 最高提示額の確認
0 wei
まだ入札されていないためコンストラクトの残高が0etherで、最高提示者がオーナーアドレス(Main account)になっています。
最初の入札
アカウント1から最初の入札を行ってみます。
入札前にアカウント1の残高確認を確認します。
[アカウント1の残高]
アカウント1からBid関数をコールして、10etherをbid(入札)します。
[最初の入札]
入札後のアカウント1の残高は次の通りです。
[アカウント1の残高]
10ether減っていることが確認できます。
最初の入札後のコンストラクトの状態を確認します。
[コンストラクトの状態]
- コンストラクトの残高確認
10 ether - 最高提示者のアドレス確認
Account1 - 最高提示額の確認
10000000000000000000 wei
アカウント1が最高提示者となり、コンストラクトの残高が10ehterに増えていることが確認できます。
2回目の入札
アカウント2から、2回目の入札を行います。
入札前のアカウント2の残高は次の通りです。
[アカウント2の残高]
アカウント2からBid関数をコールして、20etherをbid(入札)します。
[2回目の入札]
入札後のアカウント2の残高は次の通りです。
[アカウント2の残高]
20ether減っていることが確認できます。
2回目の入札後のコンストラクトの状態を確認します。
[コンストラクトの状態]
- コンストラクトの残高確認
20 ether - 最高提示者のアドレス確認
Account2 - 最高提示額の確認
20000000000000000000 wei
アカウント2が最高提示者となり、コンストラクトの残高が20ehterに増えていることが確認できます。
最初の入札者への返金確認
アカウント2が最高提示額となったため、アカウント1へ返金処理が行われているはずです。
アカウント1の残高を確認します。
[アカウント1の残高]
10etherが返金され、アカウント1の残高が入札前の状態に戻っていることが確認できました。
以上で、一通りのオークションとしての動作が確認できたことになります。
脆弱性
実はこのコンストラクトでは悪意のあるコンストラクトからの攻撃に弱いという問題があります。
次回は、悪意のあるコンストラクトを作成し、このオークション用のコンストラクトに対して攻撃を行ってみます。