aboutsummaryrefslogtreecommitdiffstats
path: root/docs/introduction-to-smart-contracts.rst
diff options
context:
space:
mode:
authorDenton Liu <liu.denton+github@gmail.com>2016-05-25 01:57:36 +0800
committerDenton Liu <liu.denton+github@gmail.com>2016-05-30 21:44:33 +0800
commit49f5bc7ce946bb2100406b0fb20d3e73d3da4292 (patch)
tree1f21561166285a5692bac8c4b326f9ccd1a5bf85 /docs/introduction-to-smart-contracts.rst
parent652bb0e8c18f5c408f8547a0d83da92a2c15deec (diff)
downloaddexon-solidity-49f5bc7ce946bb2100406b0fb20d3e73d3da4292.tar.gz
dexon-solidity-49f5bc7ce946bb2100406b0fb20d3e73d3da4292.tar.zst
dexon-solidity-49f5bc7ce946bb2100406b0fb20d3e73d3da4292.zip
Changed inline code syntax
Changed from :code:`<inline>` to ``<inline>``
Diffstat (limited to 'docs/introduction-to-smart-contracts.rst')
-rw-r--r--docs/introduction-to-smart-contracts.rst50
1 files changed, 25 insertions, 25 deletions
diff --git a/docs/introduction-to-smart-contracts.rst b/docs/introduction-to-smart-contracts.rst
index d9d1b6cd..fe51abe0 100644
--- a/docs/introduction-to-smart-contracts.rst
+++ b/docs/introduction-to-smart-contracts.rst
@@ -32,20 +32,20 @@ Storage
A contract in the sense of Solidity is a collection of code (its functions) and
data (its *state*) that resides at a specific address on the Ethereum
-blockchain. The line :code:`uint storedData;` declares a state variable called :code:`storedData` of
-type :code:`uint` (unsigned integer of 256 bits). You can think of it as a single slot
+blockchain. The line ``uint storedData;`` declares a state variable called ``storedData`` of
+type ``uint`` (unsigned integer of 256 bits). You can think of it as a single slot
in a database that can be queried and altered by calling functions of the
code that manages the database. In the case of Ethereum, this is always the owning
-contract. And in this case, the functions :code:`set` and :code:`get` can be used to modify
+contract. And in this case, the functions ``set`` and ``get`` can be used to modify
or retrieve the value of the variable.
-To access a state variable, you do not need the prefix :code:`this.` as is common in
+To access a state variable, you do not need the prefix ``this.`` as is common in
other languages.
This contract does not yet do much apart from (due to the infrastructure
built by Ethereum) allowing anyone to store a single number that is accessible by
anyone in the world without (feasible) a way to prevent you from publishing
-this number. Of course, anyone could just call :code:`set` again with a different value
+this number. Of course, anyone could just call ``set`` again with a different value
and overwrite your number, but the number will still be stored in the history
of the blockchain. Later, we will see how you can impose access restrictions
so that only you can alter the number.
@@ -98,11 +98,11 @@ registering with username and password - all you need is an Ethereum keypair.
This contract introduces some new concepts, let us go through them one by one.
-The line :code:`address public minter;` declares a state variable of type address
-that is publicly accessible. The :code:`address` type is a 160 bit value
+The line ``address public minter;`` declares a state variable of type address
+that is publicly accessible. The ``address`` type is a 160 bit value
that does not allow any arithmetic operations. It is suitable for
storing addresses of contracts or keypairs belonging to external
-persons. The keyword :code:`public` automatically generates a function that
+persons. The keyword ``public`` automatically generates a function that
allows you to access the current value of the state variable.
Without this keyword, other contracts have no way to access the variable
and only the code of this contract can write to it.
@@ -117,7 +117,7 @@ get the idea - the compiler figures that out for you.
.. index:: mapping
-The next line, :code:`mapping (address => uint) public balances;` also
+The next line, ``mapping (address => uint) public balances;`` also
creates a public state variable, but it is a more complex datatype.
The type maps addresses to unsigned integers.
Mappings can be seen as hashtables which are
@@ -127,7 +127,7 @@ too far, though, as it is neither possible to obtain a list of all keys of
a mapping, nor a list of all values. So either keep in mind (or
better, keep a list or use a more advanced data type) what you
added to the mapping or use it in a context where this is not needed,
-like this one. The accessor function created by the :code:`public` keyword
+like this one. The accessor function created by the ``public`` keyword
is a bit more complex in this case. It roughly looks like the
following::
@@ -140,12 +140,12 @@ single account.
.. index:: event
-The line :code:`event Sent(address from, address to, uint value);` declares
+The line ``event Sent(address from, address to, uint value);`` declares
a so-called "event" which is fired in the last line of the function
-:code:`send`. User interfaces (as well as server appliances of course) can
+``send``. User interfaces (as well as server appliances of course) can
listen for those events being fired on the blockchain without much
cost. As soon as it is fired, the listener will also receive the
-arguments :code:`from`, :code:`to` and :code:`value`, which makes it easy to track
+arguments ``from``, ``to`` and ``value``, which makes it easy to track
transactions. In order to listen for this event, you would use ::
Coin.Sent().watch({}, '', function(error, result) {
@@ -159,22 +159,22 @@ transactions. In order to listen for this event, you would use ::
}
}
-Note how the automatically generated function :code:`balances` is called from
+Note how the automatically generated function ``balances`` is called from
the user interface.
.. index:: coin
-The special function :code:`Coin` is the
+The special function ``Coin`` is the
constructor which is run during creation of the contract and
cannot be called afterwards. It permanently stores the address of the person creating the
-contract: :code:`msg` (together with :code:`tx` and :code:`block`) is a magic global variable that
-contains some properties which allow access to the blockchain. :code:`msg.sender` is
+contract: ``msg`` (together with ``tx`` and ``block``) is a magic global variable that
+contains some properties which allow access to the blockchain. ``msg.sender`` is
always the address where the current (external) function call came from.
Finally, the functions that will actually end up with the contract and can be called
-by users and contracts alike are :code:`mint` and :code:`send`.
-If :code:`mint` is called by anyone except the account that created the contract,
-nothing will happen. On the other hand, :code:`send` can be used by anyone (who already
+by users and contracts alike are ``mint`` and ``send``.
+If ``mint`` is called by anyone except the account that created the contract,
+nothing will happen. On the other hand, ``send`` can be used by anyone (who already
has some of these coins) to send coins to anyone else. Note that if you use
this contract to send coins to an address, you will not see anything when you
look at that address on a blockchain explorer, because the fact that you sent
@@ -301,7 +301,7 @@ If the target account contains code, that code is executed and
the payload is provided as input data.
If the target account is the zero-account (the account with the
-address :code:`0`), the transaction creates a **new contract**.
+address ``0``), the transaction creates a **new contract**.
As already mentioned, the address of that contract is not
the zero address but an address derived from the sender and
its number of transaction sent (the "nonce"). The payload
@@ -323,7 +323,7 @@ the transaction and to pay for this execution. While the EVM executes the
transaction, the gas is gradually depleted according to specific rules.
The **gas price** is a value set by the creator of the transaction, who
-has to pay :code:`gas_price * gas` up front from the sending account.
+has to pay ``gas_price * gas`` up front from the sending account.
If some gas is left after the execution, it is refunded in the same way.
If the gas is used up at any point (i.e. it is negative),
@@ -410,7 +410,7 @@ Delegatecall / Callcode and Libraries
There exists a special variant of a message call, named **delegatecall**
which is identical to a message call apart from the fact that
the code at the target address is executed in the context of the calling
-contract and :code:`msg.sender` and :code:`msg.value` do not change their values.
+contract and ``msg.sender`` and ``msg.value`` do not change their values.
This means that a contract can dynamically load code from a different
address at runtime. Storage, current address and balance still
@@ -452,9 +452,9 @@ Selfdestruct
============
The only possibility that code is removed from the blockchain is
-when a contract at that address performs the :code:`SELFDESTRUCT` operation.
+when a contract at that address performs the ``SELFDESTRUCT`` operation.
The remaining Ether stored at that address is sent to a designated
target and then the storage and code is removed.
-Note that even if a contract's code does not contain the :code:`SELFDESTRUCT`
+Note that even if a contract's code does not contain the ``SELFDESTRUCT``
opcode, it can still perform that operation using delegatecall or callcode.