2015-12-07 20:16:25 +00:00
|
|
|
###############
|
|
|
|
Common Patterns
|
|
|
|
###############
|
|
|
|
|
2016-07-08 16:21:57 +00:00
|
|
|
.. index:: withdrawal
|
|
|
|
|
2016-07-09 23:01:27 +00:00
|
|
|
.. _withdrawal_pattern:
|
|
|
|
|
2016-07-08 16:21:57 +00:00
|
|
|
*************************
|
|
|
|
Withdrawal from Contracts
|
|
|
|
*************************
|
|
|
|
|
|
|
|
The recommended method of sending funds after an effect
|
2016-07-11 14:28:20 +00:00
|
|
|
is using the withdrawal pattern. Although the most intuitive
|
|
|
|
method of sending Ether, as a result of an effect, is a
|
2018-09-25 17:08:04 +00:00
|
|
|
direct ``transfer`` call, this is not recommended as it
|
2016-07-08 16:21:57 +00:00
|
|
|
introduces a potential security risk. You may read
|
|
|
|
more about this on the :ref:`security_considerations` page.
|
|
|
|
|
2018-09-25 17:08:04 +00:00
|
|
|
The following is an example of the withdrawal pattern in practice in
|
2016-08-11 14:28:53 +00:00
|
|
|
a contract where the goal is to send the most money to the
|
2016-08-12 15:03:58 +00:00
|
|
|
contract in order to become the "richest", inspired by
|
|
|
|
`King of the Ether <https://www.kingoftheether.com/>`_.
|
2016-07-08 16:21:57 +00:00
|
|
|
|
2016-08-11 14:28:53 +00:00
|
|
|
In the following contract, if you are usurped as the richest,
|
2017-03-16 11:20:39 +00:00
|
|
|
you will receive the funds of the person who has gone on to
|
2016-08-11 18:34:36 +00:00
|
|
|
become the new richest.
|
2016-07-11 19:34:46 +00:00
|
|
|
|
2016-08-11 14:28:53 +00:00
|
|
|
::
|
2016-07-11 19:34:46 +00:00
|
|
|
|
2019-01-02 16:25:16 +00:00
|
|
|
pragma solidity ^0.5.0;
|
2016-09-05 11:54:54 +00:00
|
|
|
|
2016-08-11 14:28:53 +00:00
|
|
|
contract WithdrawalContract {
|
|
|
|
address public richest;
|
|
|
|
uint public mostSent;
|
2016-07-11 19:34:46 +00:00
|
|
|
|
2016-08-12 15:07:02 +00:00
|
|
|
mapping (address => uint) pendingWithdrawals;
|
2016-08-11 18:34:36 +00:00
|
|
|
|
2018-07-02 14:25:54 +00:00
|
|
|
constructor() public payable {
|
2016-08-11 14:28:53 +00:00
|
|
|
richest = msg.sender;
|
|
|
|
mostSent = msg.value;
|
2016-07-08 16:21:57 +00:00
|
|
|
}
|
|
|
|
|
2017-12-12 18:47:30 +00:00
|
|
|
function becomeRichest() public payable returns (bool) {
|
2016-08-11 14:28:53 +00:00
|
|
|
if (msg.value > mostSent) {
|
2016-08-12 15:07:02 +00:00
|
|
|
pendingWithdrawals[richest] += msg.value;
|
2016-08-11 14:28:53 +00:00
|
|
|
richest = msg.sender;
|
|
|
|
mostSent = msg.value;
|
2016-08-10 15:11:13 +00:00
|
|
|
return true;
|
2016-08-24 19:28:07 +00:00
|
|
|
} else {
|
2016-08-10 15:11:13 +00:00
|
|
|
return false;
|
|
|
|
}
|
2016-07-08 16:21:57 +00:00
|
|
|
}
|
|
|
|
|
2017-12-12 18:47:30 +00:00
|
|
|
function withdraw() public {
|
2016-08-12 15:07:02 +00:00
|
|
|
uint amount = pendingWithdrawals[msg.sender];
|
|
|
|
// Remember to zero the pending refund before
|
|
|
|
// sending to prevent re-entrancy attacks
|
|
|
|
pendingWithdrawals[msg.sender] = 0;
|
2017-05-02 12:12:25 +00:00
|
|
|
msg.sender.transfer(amount);
|
2016-07-11 19:34:46 +00:00
|
|
|
}
|
2016-08-11 14:28:53 +00:00
|
|
|
}
|
2016-07-11 19:34:46 +00:00
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
This is as opposed to the more intuitive sending pattern:
|
2016-07-11 19:34:46 +00:00
|
|
|
|
2016-08-11 14:28:53 +00:00
|
|
|
::
|
2016-07-11 19:34:46 +00:00
|
|
|
|
2019-01-02 16:25:16 +00:00
|
|
|
pragma solidity ^0.5.0;
|
2016-09-05 11:54:54 +00:00
|
|
|
|
2016-08-11 14:28:53 +00:00
|
|
|
contract SendContract {
|
2018-09-05 15:59:55 +00:00
|
|
|
address payable public richest;
|
2016-08-11 14:28:53 +00:00
|
|
|
uint public mostSent;
|
2016-08-11 18:34:36 +00:00
|
|
|
|
2018-07-02 14:25:54 +00:00
|
|
|
constructor() public payable {
|
2016-08-11 14:28:53 +00:00
|
|
|
richest = msg.sender;
|
|
|
|
mostSent = msg.value;
|
2016-07-08 16:21:57 +00:00
|
|
|
}
|
|
|
|
|
2017-12-12 18:47:30 +00:00
|
|
|
function becomeRichest() public payable returns (bool) {
|
2016-08-11 14:28:53 +00:00
|
|
|
if (msg.value > mostSent) {
|
2017-05-02 12:12:25 +00:00
|
|
|
// This line can cause problems (explained below).
|
2017-04-19 18:12:45 +00:00
|
|
|
richest.transfer(msg.value);
|
2016-08-11 14:28:53 +00:00
|
|
|
richest = msg.sender;
|
|
|
|
mostSent = msg.value;
|
2016-08-10 15:11:13 +00:00
|
|
|
return true;
|
2016-08-24 19:28:07 +00:00
|
|
|
} else {
|
2016-08-10 15:11:13 +00:00
|
|
|
return false;
|
|
|
|
}
|
2016-07-08 16:21:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-11 14:28:53 +00:00
|
|
|
Notice that, in this example, an attacker could trap the
|
2016-08-11 18:34:36 +00:00
|
|
|
contract into an unusable state by causing ``richest`` to be
|
2017-05-02 12:12:25 +00:00
|
|
|
the address of a contract that has a fallback function
|
|
|
|
which fails (e.g. by using ``revert()`` or by just
|
2018-08-01 11:32:26 +00:00
|
|
|
consuming more than the 2300 gas stipend transferred to them). That way,
|
2017-05-02 12:12:25 +00:00
|
|
|
whenever ``transfer`` is called to deliver funds to the
|
|
|
|
"poisoned" contract, it will fail and thus also ``becomeRichest``
|
|
|
|
will fail, with the contract being stuck forever.
|
|
|
|
|
|
|
|
In contrast, if you use the "withdraw" pattern from the first example,
|
|
|
|
the attacker can only cause his or her own withdraw to fail and not the
|
|
|
|
rest of the contract's workings.
|
2016-07-08 16:21:57 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
.. index:: access;restricting
|
|
|
|
|
|
|
|
******************
|
|
|
|
Restricting Access
|
|
|
|
******************
|
|
|
|
|
|
|
|
Restricting access is a common pattern for contracts.
|
|
|
|
Note that you can never restrict any human or computer
|
|
|
|
from reading the content of your transactions or
|
|
|
|
your contract's state. You can make it a bit harder
|
|
|
|
by using encryption, but if your contract is supposed
|
|
|
|
to read the data, so will everyone else.
|
|
|
|
|
|
|
|
You can restrict read access to your contract's state
|
|
|
|
by **other contracts**. That is actually the default
|
2016-05-24 17:57:36 +00:00
|
|
|
unless you declare make your state variables ``public``.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
Furthermore, you can restrict who can make modifications
|
|
|
|
to your contract's state or call your contract's
|
2017-10-04 12:35:05 +00:00
|
|
|
functions and this is what this section is about.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. index:: function;modifier
|
|
|
|
|
|
|
|
The use of **function modifiers** makes these
|
|
|
|
restrictions highly readable.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2018-09-24 12:46:23 +00:00
|
|
|
pragma solidity >=0.4.22 <0.6.0;
|
2016-09-05 11:54:54 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract AccessRestriction {
|
|
|
|
// These will be assigned at the construction
|
|
|
|
// phase, where `msg.sender` is the account
|
|
|
|
// creating this contract.
|
|
|
|
address public owner = msg.sender;
|
|
|
|
uint public creationTime = now;
|
|
|
|
|
|
|
|
// Modifiers can be used to change
|
|
|
|
// the body of a function.
|
|
|
|
// If this modifier is used, it will
|
|
|
|
// prepend a check that only passes
|
|
|
|
// if the function is called from
|
|
|
|
// a certain address.
|
|
|
|
modifier onlyBy(address _account)
|
|
|
|
{
|
2018-01-03 14:30:01 +00:00
|
|
|
require(
|
|
|
|
msg.sender == _account,
|
|
|
|
"Sender not authorized."
|
|
|
|
);
|
2016-09-05 12:54:50 +00:00
|
|
|
// Do not forget the "_;"! It will
|
2015-12-07 20:16:25 +00:00
|
|
|
// be replaced by the actual function
|
2016-09-05 14:29:08 +00:00
|
|
|
// body when the modifier is used.
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Make `_newOwner` the new owner of this
|
|
|
|
/// contract.
|
|
|
|
function changeOwner(address _newOwner)
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2015-12-07 20:16:25 +00:00
|
|
|
onlyBy(owner)
|
|
|
|
{
|
|
|
|
owner = _newOwner;
|
|
|
|
}
|
|
|
|
|
|
|
|
modifier onlyAfter(uint _time) {
|
2018-01-03 14:30:01 +00:00
|
|
|
require(
|
|
|
|
now >= _time,
|
|
|
|
"Function called too early."
|
|
|
|
);
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Erase ownership information.
|
|
|
|
/// May only be called 6 weeks after
|
|
|
|
/// the contract has been created.
|
|
|
|
function disown()
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2015-12-07 20:16:25 +00:00
|
|
|
onlyBy(owner)
|
|
|
|
onlyAfter(creationTime + 6 weeks)
|
|
|
|
{
|
|
|
|
delete owner;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This modifier requires a certain
|
|
|
|
// fee being associated with a function call.
|
|
|
|
// If the caller sent too much, he or she is
|
|
|
|
// refunded, but only after the function body.
|
2016-09-05 14:29:08 +00:00
|
|
|
// This was dangerous before Solidity version 0.4.0,
|
|
|
|
// where it was possible to skip the part after `_;`.
|
2015-12-07 20:16:25 +00:00
|
|
|
modifier costs(uint _amount) {
|
2018-01-03 14:30:01 +00:00
|
|
|
require(
|
|
|
|
msg.value >= _amount,
|
|
|
|
"Not enough Ether provided."
|
|
|
|
);
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2015-12-07 20:16:25 +00:00
|
|
|
if (msg.value > _amount)
|
2018-08-09 13:36:00 +00:00
|
|
|
msg.sender.transfer(msg.value - _amount);
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
function forceOwnerChange(address _newOwner)
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2018-03-19 19:38:20 +00:00
|
|
|
payable
|
2015-12-07 20:16:25 +00:00
|
|
|
costs(200 ether)
|
|
|
|
{
|
|
|
|
owner = _newOwner;
|
|
|
|
// just some example condition
|
|
|
|
if (uint(owner) & 0 == 1)
|
2016-09-05 14:29:08 +00:00
|
|
|
// This did not refund for Solidity
|
|
|
|
// before version 0.4.0.
|
2015-12-07 20:16:25 +00:00
|
|
|
return;
|
2016-09-05 14:29:08 +00:00
|
|
|
// refund overpaid fees
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
A more specialised way in which access to function
|
|
|
|
calls can be restricted will be discussed
|
|
|
|
in the next example.
|
|
|
|
|
|
|
|
.. index:: state machine
|
|
|
|
|
|
|
|
*************
|
|
|
|
State Machine
|
|
|
|
*************
|
|
|
|
|
|
|
|
Contracts often act as a state machine, which means
|
|
|
|
that they have certain **stages** in which they behave
|
|
|
|
differently or in which different functions can
|
|
|
|
be called. A function call often ends a stage
|
|
|
|
and transitions the contract into the next stage
|
|
|
|
(especially if the contract models **interaction**).
|
|
|
|
It is also common that some stages are automatically
|
|
|
|
reached at a certain point in **time**.
|
|
|
|
|
|
|
|
An example for this is a blind auction contract which
|
|
|
|
starts in the stage "accepting blinded bids", then
|
|
|
|
transitions to "revealing bids" which is ended by
|
2017-04-14 03:57:14 +00:00
|
|
|
"determine auction outcome".
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. index:: function;modifier
|
|
|
|
|
|
|
|
Function modifiers can be used in this situation
|
|
|
|
to model the states and guard against
|
|
|
|
incorrect usage of the contract.
|
|
|
|
|
|
|
|
Example
|
|
|
|
=======
|
|
|
|
|
|
|
|
In the following example,
|
2016-05-24 17:57:36 +00:00
|
|
|
the modifier ``atStage`` ensures that the function can
|
2015-12-07 20:16:25 +00:00
|
|
|
only be called at a certain stage.
|
|
|
|
|
|
|
|
Automatic timed transitions
|
2016-05-24 17:57:36 +00:00
|
|
|
are handled by the modifier ``timeTransitions``, which
|
2015-12-07 20:16:25 +00:00
|
|
|
should be used for all functions.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
**Modifier Order Matters**.
|
|
|
|
If atStage is combined
|
|
|
|
with timedTransitions, make sure that you mention
|
|
|
|
it after the latter, so that the new stage is
|
|
|
|
taken into account.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
Finally, the modifier ``transitionNext`` can be used
|
2015-12-07 20:16:25 +00:00
|
|
|
to automatically go to the next stage when the
|
|
|
|
function finishes.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
**Modifier May be Skipped**.
|
2016-09-05 14:29:08 +00:00
|
|
|
This only applies to Solidity before version 0.4.0:
|
2015-12-07 20:16:25 +00:00
|
|
|
Since modifiers are applied by simply replacing
|
|
|
|
code and not by using a function call,
|
|
|
|
the code in the transitionNext modifier
|
|
|
|
can be skipped if the function itself uses
|
|
|
|
return. If you want to do that, make sure
|
2016-09-05 14:29:08 +00:00
|
|
|
to call nextStage manually from those functions.
|
|
|
|
Starting with version 0.4.0, modifier code
|
2016-08-16 14:26:57 +00:00
|
|
|
will run even if the function explicitly returns.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
::
|
|
|
|
|
2018-09-24 12:46:23 +00:00
|
|
|
pragma solidity >=0.4.22 <0.6.0;
|
2016-09-05 11:54:54 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract StateMachine {
|
|
|
|
enum Stages {
|
|
|
|
AcceptingBlindedBids,
|
|
|
|
RevealBids,
|
|
|
|
AnotherStage,
|
|
|
|
AreWeDoneYet,
|
|
|
|
Finished
|
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// This is the current stage.
|
|
|
|
Stages public stage = Stages.AcceptingBlindedBids;
|
|
|
|
|
|
|
|
uint public creationTime = now;
|
|
|
|
|
|
|
|
modifier atStage(Stages _stage) {
|
2018-01-03 14:30:01 +00:00
|
|
|
require(
|
|
|
|
stage == _stage,
|
|
|
|
"Function cannot be called at this time."
|
|
|
|
);
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function nextStage() internal {
|
|
|
|
stage = Stages(uint(stage) + 1);
|
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// Perform timed transitions. Be sure to mention
|
|
|
|
// this modifier first, otherwise the guards
|
|
|
|
// will not take the new stage into account.
|
|
|
|
modifier timedTransitions() {
|
|
|
|
if (stage == Stages.AcceptingBlindedBids &&
|
|
|
|
now >= creationTime + 10 days)
|
|
|
|
nextStage();
|
|
|
|
if (stage == Stages.RevealBids &&
|
|
|
|
now >= creationTime + 12 days)
|
|
|
|
nextStage();
|
|
|
|
// The other stages transition by transaction
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-13 14:32:35 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// Order of the modifiers matters here!
|
|
|
|
function bid()
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2016-09-05 14:29:08 +00:00
|
|
|
payable
|
2015-12-07 20:16:25 +00:00
|
|
|
timedTransitions
|
|
|
|
atStage(Stages.AcceptingBlindedBids)
|
|
|
|
{
|
|
|
|
// We will not implement that here
|
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function reveal()
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2015-12-07 20:16:25 +00:00
|
|
|
timedTransitions
|
|
|
|
atStage(Stages.RevealBids)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
// This modifier goes to the next stage
|
|
|
|
// after the function is done.
|
|
|
|
modifier transitionNext()
|
|
|
|
{
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2015-12-07 20:16:25 +00:00
|
|
|
nextStage();
|
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function g()
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2015-12-07 20:16:25 +00:00
|
|
|
timedTransitions
|
|
|
|
atStage(Stages.AnotherStage)
|
|
|
|
transitionNext
|
|
|
|
{
|
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function h()
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2015-12-07 20:16:25 +00:00
|
|
|
timedTransitions
|
|
|
|
atStage(Stages.AreWeDoneYet)
|
|
|
|
transitionNext
|
|
|
|
{
|
|
|
|
}
|
2016-05-18 15:05:28 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function i()
|
2017-12-12 18:47:30 +00:00
|
|
|
public
|
2015-12-07 20:16:25 +00:00
|
|
|
timedTransitions
|
|
|
|
atStage(Stages.Finished)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
}
|