transactions.tex

\section{Transactions and Blockchain primitives}
\label{sect:transactions}

Transactions, more appropriately \textit{operations}, specify state transitions
to
be applied to the state of the blockchain. As opposed to for example Ethereum,
where only one type of transaction exists and all additional logic is enforced
via smart contracts, \aet\ has many different kinds of transactions.
These are provided as convenient built-in functionality for frequently used
features, while all other functionality can still be realized via smart
contracts.



\subsection{AE coins}
\label{sect:aespend}

The AE coin (formerly also AE token or aeon) is the native currency of the
\aet\ blockchain. The most basic transaction is the \textbf{spend} transaction
used to
transfer AE coins from sender to receiver. The receiver can either be an
account,
oracle or smart contract. 
In addition to coin transfers and smart contract calls, a sender can also
attach an arbitrary binary
payload, which can for example be used for proof of existence, registering a
hash or file on the blockchain.

\subsubsection{Fees for usage}
AE coins are required for any operation on the \aet\ blockchain as a
transaction or \enquote{gas fee}. For smart contract calls, every state
transition
caused
by such a transaction has a \textit{computational
complexity}, both in terms of storage size and execution, and given that we are
building an open, permissionless network, we need to measure and possibly
regulate the amount of computation used. We refer to this measure as
\enquote{gas}
and
each block has a maximum amount of gas it can contain.
This gas must be bought via the AE coin and therefore only
accounts with enough coins can submit valid transactions, although it is
possible to author transactions on behalf of others. All gas, or simply fees,
is paid to miners.


\subsection{Accounts and Signatures}
\label{sect:ga}

\subsubsection{Standard accounts}
To prevent anyone from spending currency that is not theirs transactions are
authenticated either via digital signatures using
Ed25519 \cite{bernstein2012high, bernstein2006curve25519} or by user specified
logic in generalized accounts (\ref{sect:ga}).
Replay protection is achieved via a strictly increasing nonce \cite{Syverson}.
\subsubsection{Generalized accounts}

"Generalized accounts" are a way to provide more flexibility to authenticating
transactions. This can, for example, be useful when one would allow users to
sign transactions with other cryptographic primitives than the
default\footnote{Some hardware devices may be restricted to other cryptographic
signing algorithms than the default on the \blockchain.} EdDSA as mentioned in
Sect.\ \ref{sect:transactions}.

If a user wants to have a generalized account, then they must
provide a smart contract in a \textbf{attach transaction}. This
contract is thereafter attached to the given account. The contract
must have an authentication function that returns a boolean whether or
not authentication is successful. The attach transaction itself is
just like all previously mentioned transactions signed in the default
way. It turns a normal account into a generalized account, and
\textit{there is no way back}.

When an account is a generalized account, any transaction can
be wrapped in a so called \textbf{meta transaction}. That is, one
prepares an ordinary transaction in the usual way, but with a nonce set to
zero. After that, one adds additional fee, gas and authentication data to
run the smart contract. When this transaction is processed, the
authentication function in the smart contract associated with the
account is called with the provided authentication data as input. If
the authentication fails the transaction is discarded, otherwise its
inner transaction is processed.

The following smart contract is an example that allows signing with
the ECDSA algorithm \cite{johnson2001elliptic} and the popular elliptic curve
Secp256k1, used for example by Bitcoin and Ethereum
\cite{bos2014elliptic, mayer2016ecdsa}.

\begin{verbatim}
contract ECDSAAuth =
  record state = { nonce : int, owner : bytes(20) }

  entrypoint init(owner' : bytes(20)) = { nonce = 1, owner = owner' }

  stateful entrypoint authorize(n : int, s : bytes(65)) : bool =
    require(n >= state.nonce, "Nonce too low")
    require(n =< state.nonce, "Nonce too high")
    put(state{ nonce = n + 1 })
    switch(Auth.tx_hash)
      None          => abort("Not in Auth context")
      Some(tx_hash) =>
        Crypto.ecverify_secp256k1(to_sign(tx_hash, n), state.owner, s)

  function to_sign(h : hash, n : int) : hash =
    Crypto.blake2b((h, n))

\end{verbatim}

The contract is initialized by providing the public key used for
signing and the nonce (in the contract state) is set to 1. The
authentication function takes two parameters, the nonce and the signature.
The authorization function checks that the nonce is correct, and then
proceeds to fetch the TX hash from the contract environment using
\verb+Auth.tx_hash+. In this example the signature is for the Blake2b
hash of the tuple of the transaction hash and the nonce). The
authorization finally checks that the private key used for signing the
hash was from the owner.


By attaching this contract to an \aet\ account, users can sign
\aet\ transactions with their bitcoin private key. They need to
keep track, of course, what nonces they have used for this contract,
to provide the right next nonce.

\paragraph{Security considerations}

Before the authentication is performed, there is no account that one
can charge for the computational effort of running the authentication
function. After all, anyone could wrap a transaction in a \textbf{meta
  transaction} and submit it. It would be an easy attack to empty a
generalized account if the account had to pay for failed authorization
attempts. So, the gas for authentication is only charged when
successful. This opens up for another unpleasant attack.

Since there is no cost involved for the user to run an authentication
function, but the miner needs to spend execution cycles, one could
potentially write a complex function as authentication function and
extract resources from a miner by calling one's own authentication
function with failing input data. This is mitigated by not allowing
expensive chain operations in an authentication call. Moreover, miners
are free to implement any sophisticated rules for accepting
transactions in their mining pool, such that they can reject this
behaviour when observed.

Using different signature algorithms is only one of many possible uses
of generalized accounts. Other uses cases can be multi-sig, spending
limits (per week/month), limiting the transaction types, and more. For
these applications smart contracts have to be written. Utmost care
needs to be taken when implementing the authorization
function in these smart contracts. If the contract does not enforce
integrity checking or replay protection, then it will be vulnerable to
abuse.



\subsection{ÆNS and .chain name space}
\label{sect:aens}

By default all objects addressable within the blockchain are identified by
256 bit numbers. Just like users of the web prefer remembering DNS names over
IP addresses, users of \aet\ have the option to using names. Currently all
names have the extension \textit{.chain}, e.g. \textit{superhero.chain}.

Major challenges for a naming system are to offer a reasonably fair system to
distribute names and discourage name squatting. To achieve those two goals we
settled on using a first price auction for short names, which are assumed to be
more coveted. Names longer than twelve characters can be registered instantly.

The auction has two parameters, the initial starting bid and closing timeout
after the last bit, which are adjusted based on the name being auctioned.
For example, the 4 character name \textit{hero}, starts with an initial
bid of 134.6269 coins and the auction would be open 29760 blocks (approx 62
days) after the last valid bid.
Each bid must be at least 5\% higher than the previous one in order to be
valid. Every successful bid will lock up the given number of coins and free
up the coins of the previously highest bid.

The actual process of claiming a name requires a bit of setup to prevent
\textit{front running}, where an observer snatches up a name before someone
else by observing unconfirmed transactions in the network and submitting a
competing registration attempt.

To prevent against front running, the first step in reserving a name is the
\textbf{preclaim transaction}. The pre-claim contains the hash of a combination
of the desired name and a random number (called \textit{salt}). An observer is
unable to guess the combination of name and random number, which prevents the
front running.

After the preclaim is accepted, the claimant reveals the name and salt in the
\textbf{claim transaction}. If name and salt produce the hash in the preclaim,
then they can either claim the name directly or an auction is started.

There is however still a potential for front running by putting a preclaim and
claim transaction into a block upon seeing an unconfirmed claim. This is
mitigated by requiring the preclaim and the claim for a given name to be in
different generations and therefore different blocks.

If the claim triggered an auction, bids can be submitted by sending claims with
the desired name, salt set to zero and a greater amount of coins than any
previous bids.

Once the name has been registered, an \textbf{update transaction} is needed to
point the name to something, for example an account. Additionally, there is
a \textbf{transfer transaction} to change the owner of a name and a
\textbf{revoke transaction} to free the name.
And even without active revocation, names expire after a while, unless renewed
in time with an update transaction.

When a name has been assigned to an owner and an update transaction has pointed
this name to an account, then one can use the \textit{name hash} of the name
instead of an account in, for example, a spend transaction.

It is important to realize that the names are part of the blockchain
logic. A user should not trust any third party to perform a name lookup on
chain and then substitute the name by an account. If a user want to
transfer tokens to Emin, the user should put the name hash of
\textit{emin.chain} in the transaction and sign this transaction.

\subsection{Oracles for data from outside}
\label{sect:aeoracle}

Oracles are a mechanism to bring arbitrary external data onto the blockchain,
which can then be used in smart contracts. This can be sensor data, news
events, stock prices, results of a match, supply chain data, etc.
Assessing authenticity of external data
\cite{zhang2016town,guarnizo2019pdfs, adler2018astraea} is still a somewhat
open problem but can be solved if the availability of public key crypto
systems are available to all parties. But in general oracles provide data
without robust security guarantees.

Oracles are announced to the chain by a \textbf{register oracle transaction}.
This specifies in what format the oracle expects its queries and in what format
it is going to respond. The register oracle transaction also includes the fee
of the queries to this oracle. Each query must supply that fee in order to be
answered.

After an oracle has been registered on chain, any user can post a \textbf{query
oracle transaction} with a properly formatted query.
Oracle operators monitor the blockchain for queries and ideally post
\textbf{oracle response transactions} with answers in the predefined format.
This makes the answer available on the blockchain and thus also available to
any smart contract.
It is worth noting, that any oracle answers are by default publicly available
and thus special care would need to be taken in order to make it private.

\subsubsection{Data as a service}

External data may come from a large database, possibly also accessible in
different
ways, but via the oracle made accessible on the blockchain. Typically
one could think of supply chain data. If supply chain data is
accessible via a trusted oracle, one could post an oracle query for
last transaction on a specific item one ordered. Although the answer
on such a query may be interesting and valuable in itself, the main
purpose of asking for it would be to use it in a contract to transfer
some tokens (goods have arrived in harbour, 20\%  of tokens are
transferred).

The above supply chain data may be anonymous enough to appear on a
blockchain. There is, however a privacy issue, external data that is
put on chain is made public. So, even if there might be an interesting
use case, one must be careful with for example personal data. If one
would have an airline oracle that given a last name and booking
reference returns flight data ``date'', ``from'' and ``destination''
airport, then this becomes public data. Having a contract pay the
travel agent when the oracle returns that the correct date and flight has
been booked, is therefore a bad idea. Even encrypting or decrypting the
data in the contract would be a bad idea, since contract state and
operations are visible.

Moreover, one cannot get paid for the same data twice, because the
first time it is posted, it becomes public. Therefore, typical data
normally is rather anonymous or invaluable to others than involved
parties, or is already/will become public, such as the weather or the
outcome of a match. Point is that one can use data that becomes
available in the future to base contractual decisions upon.

\subsubsection{Timing}

Users that post a query would normally want a response rather
quickly. Therefore, they can specify query TTL, either absolute
or relative key-block heights. A relative query TTL of 2 assures
that if the oracle does not answer within 2 key-blocks after the query
is accepted onchain, the query fee is not paid. In fact, an answer that is too
late, will not make it on chain and no contract can use it in a
decision.

Oracles have a specific lifetime, supplied in block height when
registering the oracle. After that block height, queries to the oracle
are no longer resulting in a response. The lifetime of an oracle can
be extended using an \textbf{extend oracle transaction}.


\subsection{Paying-for-others transaction wrapper}
\label{sect:payingfor}

In order to make users enthusiastic about a blockchain application,
one may want them to try it for free. However, there are always costs
involved for transaction and gas. This means that a new user has to
buy tokens at some exchange to pay for the fees. This can be considered
a hurdle for adoption. Of course, one can ask a user for an account and put
some tokens on it, but then those tokens can be used for anything.
The \aet\ solution is more powerful and can be used to pay for
just specific transactions. It can be used to pay for both transaction
fee and \enquote{gas cost} of a contract call.

Assume a game played via a contract on the blockchain. One interacts
with the game, by calling the contract. In order to get more users for
the game, the game provider could make an App that visualizes
the game and asks for a next move. This App could automatically create
an \aet\ account, even without the user being aware of it. This
account can be used to sign transactions on the blockchain, but there
are no tokens in the account. This move is then encoded in a
transaction signed by the players account in the app. The transaction
is submitted to the game provider, who inspects it to see that this
is indeed a move in the game and wraps it in a \textbf{payingfor
  transaction} signed by the game provider. The gas and fee are now
paid by the game provider's account.
Clearly this is also a way to have some trustful cross-chain
activity. The App user could provide the game provider with funds on a
different blockchain.

One can pay for any transaction apart from the payingfor transaction
itself. So even a generalized accounts meta transaction can be paid
for, as long as it recursively does not contain any other payingfor
transaction.