update v0.2.3

greenbook/fusotao-greenbook.tex

@@ -21,7 +21,7 @@
 \author{UINB Tech}
 \date{2021}
 \title{Fusotao Greenbook(Draft)\\\medskip
-  \large v0.2.2\\\medskip
+  \large v0.2.3\\\medskip
   \large https://www.fusotao.org}
 \hypersetup{
  pdfauthor={Fusotao Dev Team},
@@ -71,7 +71,7 @@ \section{Matching System}
 \begin{itemize}
     \item $matches(x, x_{i})$ is $true$
 \end{itemize}
-Blockchain is another typical serial system whose key rule is determining the order of all accepted incoming transactions. E.g. the Bitcoin network uses PoW algorithm and the Longest Chain Rule to ensure the global unique sequence of transactions. It seems natural to build a matching system on-chain just like a plain transfer function did. However, unfortunately, due to the limitation of block capacity and high latency, it is not straightforward to do it so.\\
+Blockchain is another typical serial system whose key rule is determining the order of all accepted incoming transactions. E.g. the Bitcoin network uses PoW algorithm and the Longest Chain Rule to ensure the global unique sequence of transactions. It seems natural to build a matching system on-chain just like a plain transfer function did. However, due to the limitation of block capacity and high latency, it is not straightforward to do it so.\\
 Ideally, to implement a matching system on-chain, an order must occupy 73 bytes at least:\\
 \begin{equation*}
 ID + Owner + Price + Unfilled + Direction = 73 bytes
@@ -126,30 +126,49 @@ \section{Global States}
     \Psi_{k} = (k, l, r, \lambda(\Psi_{k>>l}, \Psi_{k>>r}))
 \end{equation*}
 Back to the matching procedure, since we've done an optimized Sparse Merkle Tree so can encode the orderbook into it and only store the root hash on chain and leave the entire tree to matchers. Once a matcher executes the \(i_{th}\) event off-chain and proves it by submitting some digests at \(i-1_{th}\), a validator can simply verify the results like above.\\
-Fusotao defines 2 types of key as the leaf keys of Sparse Merkle Tree:\\
+Fusotao defines 4 types of key as the leaf keys of Sparse Merkle Tree:\\
 \begin{equation*}
     orderbook(symbol) = \lambda(1, symbol)
 \end{equation*}
 \begin{equation*}
     account(currency) = \lambda(0, currency)
 \end{equation*}
+\begin{equation*}
+    bestprice(symbol) = \lambda(2, symbol)
+\end{equation*}
+\begin{equation*}
+    orderpage(symbol, price) = \lambda(3, symbol, price)
+\end{equation*}
 where\\
 \begin{itemize}
     \item $currency$ is a 32-bits unsigned number represented currency
     \item $symbol$ is consisted of $base$ currency and $quote$ currency
+    \item $price$ is the index of orderpages sorted from best to worst
 \end{itemize}
-There are no leaf nodes for encoding orders, instead, the sum of the orderbook's size is enough for validators except the condition that the matcher doesn't pick the best makers. In the further future, we may add the best price to each orderbook node to get rid of this.\\
+
 A matcher has a specific global state at the \(i_{th}\) event which can be verified by the leaf values:\\
 \begin{equation*}
-    orderbook_{i} = ask_{i} << 128 + bid_{i}
+    orderbook_{s} = ask_{s} << 128 + bid_{s}
+\end{equation*}
+\begin{equation*}
+    account_{j} = available_{j} << 128 + freezed_{j}
 \end{equation*}
 \begin{equation*}
-    account_{i} = available_{i} << 128 + freezed_{i}
+    bestprice_{s} = askprice_{s} << 128 + bidprice_{s}
+\end{equation*}
+\begin{equation*}
+    orderpage_{s, p} = vol
 \end{equation*}
 where\\
 \begin{itemize}
-    \item all numerics are 128-bits represented unsigned fixed number with $scale$=18
+  \item $s$ represents the $symbol$
+  \item $j$ represents the $j_{th}$ account of current matching results
+  \item $p$ represents the $price$
+  \item all numerics are 128-bits represented unsigned fixed number with $scale$=18
 \end{itemize}
+
+For simplicity, we can define \(a \nabla b\) as \(a << 128 + b\).
+
 \section{Proof of Matching}
 \label{sec:org48d64ef}
 Given a user-signed event \(E_{i}\) and some merkle paths \(P_{(i-1, j)}\) at \(i-1\), a validator can verify it using a matching procedure with well-known root hash \(S_{i-1}\) stored on-chain:\\
@@ -158,37 +177,26 @@ \section{Proof of Matching}
 P_{(i-1, j)} + E_{i} \Rightarrow S_{i} + P_{(i, j)} \\
 \sum\limits_{j=0}^{n} belongs(P_{(i, j)}, S_{i}) = n
 \end{eqnarray*}
-A matcher must maintain a Sparse Merkle Tree and update it every time after the event is applied. Let \((x, y)\) be an ask-limit order's price and amount of symbol \((b/q)\) as the \(i_{th}\) event, \((x_{j}, y_{j})\) be the \(j_{th}\) maker exists at \(i-1\), then the proof generated by matcher would be (Fee not included):\\
+
+A matcher must maintain a Sparse Merkle Tree and update it every time after the event is applied and generate an associated proof which is composed of the origin command and some merkle leaves including value before and after the \(i_{th}\) event executed.\\
+Let \((x, y)\) be an ask-limit order's price and amount of symbol \((b/q)\) as the \(i_{th}\) event, \((x_{j}, y_{j})\) be the \(j_{th}\) maker exists at \(i-1\). Then the proof generated by the matcher should be (Fee excluded):\\
 \begin{equation*}
-    account(b)_{(i, j)}=account(b)_{(i-1,j)} + y_{j} << 128
+    account(b)_{(i, j)}=account(b)_{(i-1,j)} \nabla y_{j}
 \end{equation*}
 \begin{equation*}
     account(q)_{(i, j)}=account(q)_{(i-1,j)} - x_{j} \times y_{j}
 \end{equation*}
 \begin{equation*}
-    account(b)_{i}=account(b)_{i-1} - \sum\limits_{j} y_{j} << 128 + y - \sum\limits_{j} y_{j}
+    account(b)_{i}=account(b)_{i-1} - (\sum\limits_{j} y_{j} \nabla 0) + (y - \sum\limits_{j} y_{j})
 \end{equation*}
 \begin{equation*}
-    account(q)_{i}=account(q)_{i-1} + \sum\limits_{j} x_{j} \times y_{j} << 128
+    account(q)_{i}=account(q)_{i-1} \nabla \sum\limits_{j} x_{j} \times y_{j}
 \end{equation*}
 \begin{equation*}
-    orderbook(b,q)_{i}=orderbook(b,q)_{i-1} + (y - \sum\limits_{j} y_{j}) << 128 + orderbook(b,q)_{i-1} - \sum\limits_{j} y_{j}
+    \sum\limits_{p}^{x} orderpage(b,q)_{(i, p)} = \sum\limits_{p}^{x} orderpage(b,q)_{(i-1, p)} + y - \sum\limits_{j} y_{j}
 \end{equation*}
-
-Once verified, the accounts can be mutated and update the root hash stored on-chain to \(S_{i}\).\\
-\section{Substrate Implementation \& Cross-Chain}
-\label{sec:orge2652f5}
-As an abstract protocol, PoM can either be built on existing blockchains as a series of contracts or run as an independent network. Considering the gas fee and latency, we decide to implement Fusotao protocol over Substrate as a permissionless network which permits submitting proofs with zero-cost and low-latency. In this scenario, Fusotao network acts as a decentralized infrastructure rather than a specific DEX. Thus, users may not handle over their account’s ownership to a matcher but just authorize the mutation rights.\\
-Substrate is a complete blockchain framework with a set of built-in tools including Level DB storage, libp2p communication, etc. Especially, the cryptography of Substrate is fully retained in Fusotao runtime which makes it much reliable. Therefore, the Sr25519 (Schnorrkel/Ristretto x25519) keys for user signature and Ed25519 keys for node signature used in other Substrate-based networks can be recognized in Fusotao network by changing the first type byte of ss58check address to constant \(42\). The acceptable Fusotao ss58check address format is shown below:\\
 \begin{equation*}
-address = base58(type(42)+pubkey(32 bytes)+checksum(2 bytes))
+    orderbook(b,q)_{i}=orderbook(b,q)_{i-1} + (y - \sum\limits_{j} y_{j}) \nabla 0 - \sum\limits_{j} y_{j}
 \end{equation*}
-The Fusotao runtime provides a set of core APIs abount PoM:\\
-\begin{itemize}
-    \item $claim$ Claim as a matcher and prover by staking 1\% TAOs of current issurance.
-    \item $prove$ Submit the original user-signed order and associated proof.
-    \item $grant$ Authorize a matcher some tokens without transfering ownership.
-    \item $revoke$ Revoke authorization from a matcher.
-\end{itemize}
-As an isolated network, it is necessary to bring existing assets to Fusotao. Inspired by NEAR Rainbow Bridge, Fusotao provides a trustless component bridging to NEAR main net called Avatar Messenger. Avatar Messenger consists of a contract deployed on NEAR network as a light client of Fusotao, a built-in pallet integrated in Fusotao runtime as a NEAR light client and a relayer who is responsible to relay blocks to each others. Fortunately, NEAR and Substrate both support Ed25519 signed block, bridging to NEAR is much easier than bridging to Ethereum. Because a finalized block will always be within the canonical chain, which means both clients do not need worry about the chain fork, and the relayer doesn’t have to submit all blocks.\\
+Once verified, the accounts can be mutated following the decoded account leaves and update the root hash stored on-chain to \(S_{i}\).\\
 \end{document}