-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathtransparent-account.tex
48 lines (34 loc) · 5.09 KB
/
transparent-account.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
\section{Transparent Account-based Wallets}
\label{transparent-account}
For simplicity and without loss of generality we assume an Ethereum-like cryptocurrency.
Because in the account model there is no need for change outputs, new addresses are not automatically derived by wallets. New addresses are derived and used only by the explicit request of the user. Traditionally account-based wallets only hold a single address and public key, and we will assume the same in this section for simplification.
A transaction description is comprised of the address of the recipient, an amount of cryptocurrency and a fee. In Ethereum this fee takes the form of a gas price~\cite{wood2014ethereum}.
To fund a transaction description the wallet performs the following steps:
\begin{enumerate}
\item Fill in a valid address corresponding to a public key that:
\begin{enumerate}
\item holds at least as much cryptocurrency in its balance than what will be spent in the transaction and
\item is derivable from the seed.
\end{enumerate}
\item Fill in the valid nonce in order to make this transaction spendable.
\item Sign the transaction with the appropriate secret key.
\end{enumerate}
The transaction can subsequently be broadcast and accepted by the network.
We remark that an account-based wallet may offer limited functionality. For example, having access to the state it is easy to know the nonce and balance of any address of interest, thus funding a transaction description is straightforward. State however does not allow us to obtain the transaction history.
\subsection{Full Node}
A full node has access to the complete state and the full chain (i.e. all blocks and all their transactions), after a sync. For each derivable address, its balance and nonce can be looked up directly from the state. To obtain the transaction history for a set of addresses, every tranaction from the genesis block up to the tip must be checked.
\subsection{Explorer-based}
An explorer-based wallet as in the UTXO model connects to a trusted server and requests the list of all transactions, which then becomes its wallet state and it uses to function. It has no notion of the honestly adopted chain or any chain at all. For the account-model the differences are minimal. In Ethereum the wallet may additionally connect to a trusted Ethereum node for getting the balance or transaction count (i.e. the nonce).
\paragraph{In practice.}
Metamask~\cite{metamask} is the most popular Ethereum wallet and is explorer-based. An explorer is used in order to obtain the transaction history, usually Etherscan~\cite{etherscan}.
\subsection{SPV without history}
It is very easy to conceive how an SPV wallet for Electrum would work without history capabilities. Observe that for spendability only the nonce for the wallet's address is necessary. The nonce along with the balance are included in the state trie of Ethereum, which is committed in the form of the trie root inside every block header. Thus a wallet would work as follows:
\begin{enumerate}
\item Perform a headers sync to obtain the blockchain tip.
\item Ask for the value of the address of the user in the state trie at the tip, along with a proof for the value.
\item Verify that the value is indeed committed in the root found at the tip block header and extract the balance and nonce from it.
\end{enumerate}
\subsection{Electrum-like}
We propose a solution based on Electrum for account-based cryptocurrencies. We augment the wallet server protocol that we demonstrated in~\cref{utxo-electrum} for accounts with one more function which we call \texttt{get\_state}. The function $\texttt{get\_state}(pk, h)$ takes a public key $pk$ and a block height $h$ and returns the state $\tpl{\bal, \nonce}$\footnote{For simplification we only mind the state for Externally Owned Accounts and we completely disregard smart contracts in our accounts model.}, along with an authenticated map proof against the state trie found in the block header at height $h$.
The operation of the wallet proceeds as follows. The wallet first completes a headers-based synchronisation obtaining the honestly adopted chain. Servers which did not provide the honestly adopted chain are disregarded for the next steps. It then picks a server at random and asks for all transactions using \texttt{get\_history}. After verifying all the Merkle proofs for all transactions, it requests the state and a proof for the chain tip by invoking $\texttt{get\_state}(pk, |\chain|-1)$. It verifies this proof against the block header of its local chain tip.
It then is able to reconcile the history obtained with the confirmed state of $pk$ in order to ensure that no transactions have been omitted. First, the number of debits should be equal to the $\nonce$ found in the state, and secondly the $\bal$ should be equal to the sum of all credits minus the sum of all debits and their corresponding transaction fees. If any of these checks fail, the server lied about the history and another server is chosen for the process to repeat, until a server finally says the truth. By our standard assumption of at least one honest server this is bound to happen.