You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -241,139 +241,13 @@ \subsection{Inclusion and Exclusion Proofs}
241
241
\end{itemize}
242
242
243
243
244
-
\section{Sparse Merkle Sum Trees}\label{app:smst}
245
-
246
-
A \emph{Sparse Merkle Sum Tree}\index{Sparse Merkle Sum Tree} (SMST) extends Sparse Merkle Tree with value tracking. Each node carries both a hash and a non-negative integer value. Internal nodes sum their children's values, enabling cryptographic proofs that a leaf's value is part of a known total. This structure is used for value conservation proofs in token splitting (Sec.~\ref{sec:token-splitting}).
247
-
248
-
\subsection{Node Structure}
249
-
250
-
Each node in an SMST carries a pair $(h, v)$, where $h \in\hashtype$ is the node hash and $v \in\mathbb{N}$ is the accumulated value.
251
-
252
-
\begin{itemize}
253
-
\item\textbf{Leaf node}: $(h, v)$ where:
254
-
\begin{itemize}
255
-
\item$p \in\bitstr$ -- path label from this leaf to its parent
256
-
\item$d \in\bytes{\ast}$ -- leaf data
257
-
\item$v \in\mathbb{N}$ -- leaf value (e.g. asset amount)
258
-
\item$h = H(p, d, v)$
259
-
\end{itemize}
260
-
\item\textbf{Branch node}: $(h, v)$ where:
261
-
\begin{itemize}
262
-
\item$p \in\bitstr$ -- path label from this node to its parent
263
-
\item$(h_L, v_L)$ -- left child hash and value
264
-
\item$(h_R, v_R)$ -- right child hash and value
265
-
\item$h = H(p, h_L, v_L, h_R, v_R)$
266
-
\item$v = v_L + v_R$
267
-
\end{itemize}
268
-
\item\textbf{Root node}: Uses the fixed path label $p = 1$ in hash computation:
269
-
\begin{itemize}
270
-
\item$h = H(1, h_L, v_L, h_R, v_R)$
271
-
\item$v = v_L + v_R$
272
-
\end{itemize}
273
-
\end{itemize}
274
-
275
-
An empty child is represented by $(h, v) = (\bot, 0)$.
In addition to verifying the root hash, the accumulated sum $v_\mathsf{sum}$ at the root equals the total value in the tree, enabling value conservation checks: the verifier confirms both that the leaf value matches the claimed allocation and that the root sum matches the original token's total value for the given asset.
A \emph{Radix Sparse Merkle Tree}\index{Radix Sparse Merkle Tree} (RSMT) is a leaf-anchored, path-compressed binary Merkle tree over a 256-bit key space. It authenticates a finite map $k \mapsto v$, where every stored key appears as exactly one leaf and every internal node records the absolute bit position at which its descendant keys bifurcate. The implementation documented here uses LSB-first bit order.\footnote{Reference Python implementation: \href{https://github.com/unicitynetwork/unicity-yellowpaper-tex/blob/main/ndrsmt3o.py}{\texttt{ndrsmt3o.py}}.} Each leaf hash commits to the full 256-bit key, and each internal node hash commits to the explicit bifurcation depth. Consequently, splitting an edge above an unchanged subtree does not alter that subtree's hash: batch insertion rehashes only the changed search frontier and the newly created nodes. The tree supports inclusion certificates, non-inclusion certificates and consistency proofs.
246
+
A \emph{Radix Sparse Merkle Tree}\index{Radix Sparse Merkle Tree} (RSMT) is a leaf-anchored, path-compressed binary Merkle tree over a 256-bit key space. It authenticates a finite map $k \mapsto v$, where every stored key appears as exactly one leaf and every internal node records the absolute bit position at which its descendant keys bifurcate. The implementation documented here uses byte-order-preserving LSB-in-byte bit numbering. Each leaf hash commits to the full 256-bit key, and each internal node hash commits to the explicit bifurcation depth. Consequently, splitting an edge above an unchanged subtree does not alter that subtree's hash: batch insertion rehashes only the changed search frontier and the newly created nodes. The tree supports inclusion certificates, non-inclusion certificates and consistency proofs.
373
247
374
248
\subsection{Tree Structure}
375
249
376
-
Keys are elements of $\bytes{32}$ (256 bits), addressed in LSB-first order\footnote{See Appendix~\ref{app:ordering} for bit-string conventions.}. Bit position $i$ means the $i$-th least significant bit.
250
+
Keys are elements of $\bytes{32}$ (256 bits). Write $k=k_0\|k_1\|\cdots\|k_{31}$in wire byte order. Bit position $i$ addresses bit $i\bmod8$ of byte $k_{\lfloor i/8\rfloor}$, where bit$0$ of a byte is its least significant bit. Thus depth $0$ reads the low bit of $k_0$, depth $7$ reads the high bit of $k_0$, depth $8$ reads the low bit of $k_1$, and depth $255$ reads the high bit of $k_{31}$. Tree traversal MUST NOT reinterpret the key as a single big-endian integer for bit addressing.
When a shard $\sigma$ is split into two sub-shards $\sigma\|0$ and $\sigma\|1$ (Sec.~\ref{sec:sharding}), the RSMT maintained by the parent shard must be partitioned accordingly: each successor keeps only those leaves whose keys route to it under the sharding function $f_{\mathcal{SH}}$. In the LSB-first convention of Section~\ref{sec:rsmt-sort-order}, a key $k$ belongs to $\sigma\| b$ if bit $|\sigma|$ of $k$ equals $b$.
393
+
When a shard $\sigma$ is split into two sub-shards $\sigma\|0$ and $\sigma\|1$ (Sec.~\ref{sec:sharding}), the RSMT maintained by the parent shard must be partitioned accordingly: each successor keeps only those leaves whose keys route to it under the sharding function $f_{\mathcal{SH}}$. In the bit-numbering convention of Section~\ref{app:rsmt}, a key $k$ belongs to $\sigma\| b$ if bit $|\sigma|$ of $k$ equals $b$.
An inclusion certificate is a pair $C^\mathsf{inc} = (\mathit{bitmap}, \mathit{siblings})$ where:
583
457
\begin{itemize}
584
-
\item$\mathit{bitmap} \in\bytes{32}$ -- a 256-bit vector. Bit $d$ is set if and only if a sibling hash is required at depth $d$ on the path from the leaf to the root.
\item$\mathit{bitmap} \in\bytes{32}$ -- a 256-bit vector. Bit $d$ is stored as bit $d\bmod8$ of byte $\lfloor d/8\rfloor$ and is set if and only if a sibling hash is required at depth $d$ on the path from the leaf to the root.
\noindent\textbf{Wire format}: $k_\ell[32] \,\|\, h_\ell[32] \,\|\,\mathit{bitmap}[32] \,\|\, s_1[32] \,\|\,\ldots\,\|\, s_n[32]$, for a total of $96 + 32n$ bytes.
The batch and proof use \emph{LSB-first traversal order}. The sort key of a 256-bit key $k$ is obtained by reversing the byte order of $k$ and then independently reversing the bits within each byte. This places the least significant bit of the key first in lexicographic order, matching the tree's branching order.
580
+
The batch and proof use the tree traversal order defined in Section~\ref{app:rsmt}. The sort key of a 256-bit key $k=k_0\|k_1\|\cdots\|k_{31}$ is obtained by independently reversing the bits within each byte while preserving byte order. This places bit $0$of $k_0$first in lexicographic order, then bit $1$ of $k_0$, and so on through bit $7$ of $k_{31}$, matching the tree's branching order.
707
581
708
582
\subsubsection{Proof Format}
709
583
710
-
The proof $\pi$ is a flat stream of opcodes emitted from a post-order, LSB-first traversal of the tree:
584
+
The proof $\pi$ is a flat stream of opcodes emitted from a post-ordertraversal of the tree in the order defined above:
711
585
712
586
\begin{center}
713
587
\begin{tabular}{clcl}
@@ -829,3 +703,85 @@ \subsubsection{Verification}
829
703
\item Verify the ZK proof, obtaining authentic public inputs $h'$, $h$
830
704
\item Confirm these values match the claimed Input Reco rd
831
705
\end{enumerate}
706
+
707
+
708
+
\section{Radix Sparse Merkle Sum Trees}\label{app:rsmst}
709
+
710
+
A \emph{Radix Sparse Merkle Sum Tree}\index{Radix Sparse Merkle Sum Tree} (RSMST) is the radix sparse Merkle tree of Appendix~\ref{app:rsmt} with a positive amount at every leaf and an accumulated sum at every internal node. It is used for split allocation roots (Sec.~\ref{sec:token-splitting}). The tree deliberately reuses the RSMT key space, byte-order-preserving bit numbering, canonical path-compressed structure and inclusion-walk logic.
711
+
712
+
\subsection{Tree Structure}
713
+
714
+
Keys are 32-byte strings. For token splitting the key is the output token identifier $\mathsf{id}_j$, the leaf data is the 32-byte output commitment $d_j$, and the leaf amount is the positive asset allocation $v_j(\mathsf{aid})$.
715
+
716
+
An RSMST leaf carries $(k,d,v)$ where $k,d\in\bytes{32}$ and $1\leq v<2^{256}$. An internal node carries an absolute bifurcation depth $\delta\in\{0,\ldots,255\}$ and two child pairs $(h_L,v_L)$ and $(h_R,v_R)$; its sum is $v_L+v_R$. Construction MUST use the same canonical path-compressed binary trie as RSMT, MUST reject duplicate keys and zero-valued leaves, and MUST reject any internal sum overflow. A split allocation tree is never empty.
717
+
718
+
For a tree $\mathcal{S}$, $\Call{RSMSTRoot}{\mathcal{S}}$ returns the root hash and root sum. If $\mathcal{S}$ has one leaf, the root hash is that leaf hash and the root sum is that leaf amount. Otherwise the root is the hash and sum of the top internal node.
719
+
720
+
\subsection{Hash Computation}
721
+
722
+
Hash inputs use fixed binary encodings, not general-purpose CBOR tuples. Let $\Call{u256}{x}$ be the 32-byte big-endian encoding of $x$ and let $\Call{u8}{\delta}$ be the one-byte encoding of $\delta$. Define one-byte domain separators:
where $0\leq n\leq256$, $\delta_i\in\{0,\ldots,255\}$ is the sibling's parent bifurcation depth, $s_i\in\hashtype$ is the sibling subtree hash, and $1\leq w_i<2^{256}$ is the sibling subtree sum. Depths MUST be strictly decreasing in proof order because the proof is ordered from the leaf toward the root. No bitmap is carried; the depth in each sibling entry fully identifies the branch step.
The verifier checks value conservation by comparing $v_\mathsf{root}$ to the authenticated source amount for the same asset. The root hash alone is not sufficient: sibling sums are verification-critical proof data because they are committed by every internal node hash.
0 commit comments