【完全保存版】fallback関数について、しっかりと学ぼう！
こちらの記事は、solidityの公式ドキュメントをもとにしています。
テストケースなどもありますので、実際に作ってみるとイメージが湧いてくると思います。
１ fallback関数とは
あるコントラクトには、下のようにA関数とB関数という２つだけの関数が存在してるとします。（fallback関数でもreceive関数でもない関数）
このコントラクトに向けて、「X関数」という存在しない関数を実行しようとします。
これはどうなるでしょうか？
また、Etherをただ送ろうとするとどうなるでしょう？
結論としては、コントラクトに「fallback」関数がないと、エラーになります。（receive関数、payableについては、一旦無視します。）
逆に言うと、「fallback」関数があれば、これらの処理は可能になります。
このように、コントラクト内にない関数を実行された時などに呼ばれる関数が「fallback」関数です。
２ payable修飾子について
次に、「payable」という修飾子について考えます。
こちらはEtherを受け取るために必要なキーワードのようなものです。
つまり、下のように「fallback」関数に「payable」がついていなければ、Etherを受け取ることができません。
つまり、下のように、「fallback」関数に「payable」がついていれば、Etherを受け取ることができます。
３ receive関数について
ただ、Etherを受けるだけの関数として、「receive」関数があります。
Etherを受け取るので「payable」が必要です。
「payable」の「fallback」関数があるときは、こちらのreceive関数を入れることが推奨されています。
これがあることによって、下のように、役割が明確になります。
となると、Etherを受け取る処理は「receive」関数に任せて、「fallback」関数は「payable」を外せば良いのではと思うかもしれません。
しかし、そうとも限りません。
このように、「Etherを送るだけ」ではなく、処理も行いたい場合は、①に該当します。
そのため、そのようなケースも想定する場合は、「payable」ありの「fallback」関数が必要です。
４ ガス制限について
receive関数には「Etherを受け取るだけ」ですので、多くのガスは必要ありません。
他の処理が行われてしまわないよう、2,300ガスまでしか使えないように、制限されています。
では、fallback関数についても考えてみましょう。
receive関数がなければ、下のように、「Etherを受け取るだけの処理」はfallback関数が行います。
（ただし、「payable」ありのfallback関数があるときはreceive関数をつけることが推奨されているので、これは非推奨の話です。）
この場合は、やっていることは「receive」関数と同じですので、2,300ガスに制限されます。
注
こちらのfallback関数のガス制限について、他の多くの日本語の記事と異なる内容になっていると思います。
公式を読み解いた結果、上の帰結になると考えていますが、もし理解が誤っていた場合は修正いたします。
今回は以上です。
いいなと思ったら応援しよう！
