zh_ton.tex

\documentclass[12pt,oneside]{article}
\usepackage{xeCJK}
\setCJKmainfont{SimSun}

\usepackage[T1]{fontenc}
%\usepackage{euler}
\usepackage{amssymb, amsmath, amsfonts, stmaryrd}
\usepackage[mathscr]{euscript}
\usepackage{mathrsfs}
\usepackage{theorem}
\usepackage[english]{babel}
\usepackage{bm}
\usepackage[all]{xy}
%\usepackage{chngcntr}
%\CompileMatrices
\usepackage[bookmarks=false,pdfauthor={Nikolai Durov},pdftitle={The Open Network}]{hyperref}
\usepackage{fancyhdr}
\usepackage{caption}
%
\setlength{\headheight}{15.2pt}
\pagestyle{fancy}
\renewcommand{\headrulewidth}{0.5pt}
%
\def\makepoint#1{\medbreak\noindent{\bf #1.\ }}
\def\zeropoint{\setcounter{subsection}{-1}}
\def\zerosubpoint{\setcounter{subsubsection}{-1}}
\def\nxpoint{\refstepcounter{subsection}%
  \smallbreak\makepoint{\thesubsection}}
\def\nxsubpoint{\refstepcounter{subsubsection}%
  \smallbreak\makepoint{\thesubsubsection}}
\def\nxsubsubpoint{\refstepcounter{paragraph}%
  \makepoint{\paragraph}}
%\setcounter{secnumdepth}{4}
%\counterwithin{paragraph}{subsubsection}
\def\refpoint#1{{\rm\textbf{\ref{#1}}}}
\let\ptref=\refpoint
\def\embt(#1.){\textbf{#1.}}
\def\embtx(#1){\textbf{#1}}
\long\def\nodo#1{}
%
%\def\markbothsame#1{\markboth{#1}{#1}}
\fancyhf{}
\fancyfoot[C]{\thepage}
\def\markbothsame#1{\fancyhead[C]{#1}}
\def\mysection#1{\section{#1}\fancyhead[C]{\textsc{Chapter \textbf{\thesection.} #1}}}
\def\mysubsection#1{\subsection{#1}\fancyhead[C]{\small{\textsc{\textrm{\thesubsection.} #1}}}}
\def\myappendix#1{\section{#1}\fancyhead[C]{\textsc{Appendix \textbf{\thesection.} #1}}}
%
\let\tp=\textit
\let\vr=\textit
\def\workchainid{\vr{workchain\_id\/}}
\def\shardpfx{\vr{shard\_prefix}}
\def\accountid{\vr{account\_id\/}}
\def\currencyid{\vr{currency\_id\/}}
\def\uint{\tp{uint}}
\def\opsc#1{\operatorname{\textsc{#1}}}
\def\blkseqno{\opsc{blk-seqno}}
\def\blkprev{\opsc{blk-prev}}
\def\blkhash{\opsc{blk-hash}}
\def\Hash{\opsc{Hash}}
\def\Sha{\opsc{sha256}}
\def\height{\opsc{height}}
\def\len{\opsc{len}}
\def\leaf{\opsc{Leaf}}
\def\node{\opsc{Node}}
\def\root{\opsc{Root}}
\def\emptyroot{\opsc{EmptyRoot}}
\def\code{\opsc{code}}
\def\Ping{\opsc{Ping}}
\def\Store{\opsc{Store}}
\def\FindNode{\opsc{Find\_Node}}
\def\FindValue{\opsc{Find\_Value}}
\def\Bytes{\tp{Bytes}}
\def\Transaction{\tp{Transaction}}
\def\Account{\tp{Account}}
\def\State{\tp{State}}
\def\Maybe{\opsc{Maybe}}
\def\List{\opsc{List}}
\def\Block{\tp{Block}}
\def\Blockchain{\tp{Blockchain}}
\def\isValidBc{\tp{isValidBc}}
\def\evtrans{\vr{ev\_trans}}
\def\evblock{\vr{ev\_block}}
\def\Hashmap{\tp{Hashmap}}
\def\Type{\tp{Type}}
\def\nat{\tp{nat\/}}
\def\hget{\vr{hget\/}}
\def\bbB{{\mathbb{B}}}
\def\st#1{{\mathbf{#1}}}
%
\hfuzz=0.8pt

\title{The Open Network}
\author{Nikolai Durov\\
TL: Dr Awesome Doge}% a.k.a. K.O.T.
\begin{document}

%\pagestyle{myheadings}
\maketitle

\begin{abstract}
  本論文旨在首次詳述The Open Network (TON) 以及相關的區塊鏈、P2P (點對點)、分散式儲存及服務託管技術。為了確保本文件的篇幅在合理的範疇內，我們主要針對TON平台中具有獨特性和關鍵定義的功能進行探討，這些功能對於實現其明確設定的目標具有核心重要性。
\end{abstract}

\section*{緒論}
\markbothsame{緒論}

{\em The Open Network (TON)} 是一個快速、安全且可擴展的區塊鏈和網路專案，如有必要，它能夠處理每秒數百萬筆交易，對使用者和服務提供者都非常友好。我們希望它能夠承載所有目前提議和構想的合理應用程式。人們可以將TON視為一個巨大的分散式超級電腦，或者更恰當地說，一個巨大的``超級伺服器''，旨在托管和提供各種服務。

本文並非關於所有實作細節的終極參考。在開發和測試階段，部分具體內容有可能發生變更。

\clearpage
\tableofcontents

\clearpage
\mysection{TON組件的簡要描述}\label{sect:ton.components}

{\em The Open Network (TON)} 結合了以下組件：
\begin{itemize}
\item 一個靈活的多區塊鏈平台 ({\em TON Blockchain}; 參考第~\ptref{sect:blockchain}章)，能夠處理每秒數百萬筆交易，擁有圖靈完全智能合約、可升級的正式區塊鏈規格、多加密貨幣價值轉移、支持微支付通道和鏈下支付網路。{\em TON Blockchain\/} 提供了一些新的和獨特的功能，例如「自我修復」垂直區塊鏈機制 (參考~\ptref{sp:inv.sh.blk.corr}) 和 Instant Hypercube Routing (參考~\ptref{sp:instant.hypercube})，使其同時快速、可靠、可擴展和自我一致。
\item 一個點對點網路 ({\em TON P2P Network}, 或簡稱 {\em TON Network}; 參考第~\ptref{sect:network}章)，用於訪問TON區塊鏈、發送交易候選者，以及只接收客戶端感興趣的區塊鏈的部分更新（例如，與客戶端的賬戶和智能合約相關的部分），但也能支持任意分散服務，無論是否與區塊鏈相關。
\item 一種分散的文件儲存技術 {\em (TON Storage);} (參考~\ptref{sp:ex.ton.storage})，通過 {\em TON Network} 訪問，由TON Blockchain用於儲存區塊和狀態數據（快照）的存檔副本，但也可以用於儲存平台上的使用者或其他服務的任意文件，使用類似於torrent的訪問技術。
\item 一個網路代理/匿名層 {\em (TON Proxy);} (參考~\ptref{sp:ex.ton.proxy} 和~\ptref{sp:tunnels})，類似於 $I^2P$ (Invisible Internet Project)，如有必要（例如，從擁有大量加密貨幣的賬戶提交交易的節點，或希望隱藏其確切IP地址和地理位置以對抗DDoS攻擊的高風險區塊鏈validator節點），用於隱藏 {\em TON Network\/} 節點的身份和IP地址。
\item 一個類似Kademlia的分散式雜湊表 ({\em TON DHT}; 參考~\ptref{sect:kademlia})，用作 {\em TON Storage} 的「torrent tracker」(參考~\ptref{sp:distr.torr.tr})，作為 {\em TON Proxy\/} 的「input tunnel locator」(參考~\ptref{sp:loc.abs.addr})，以及作為 {\em TON Services} 的服務定位器 (參考~\ptref{sp:loc.serv})。
\item 一個提供任意服務的平台 ({\em TON Services}; 參考第~\ptref{sect:services}章)，居住在並可通過 {\em TON Network\/} 和 {\em TON Proxy} 訪問，具有正式化的界面 (參考~\ptref{sp:pub.int.smartc}) 使得瀏覽器或智能手機應用程序可以互動。這些正式界面和持久的服務入口點可以在TON Blockchain中發布 (參考~\ptref{sp:ui.ton.dns})；提供服務的實際節點可以從在TON Blockchain中發布的信息開始，通過 {\em TON DHT\/} 查找 (參考~\ptref{sp:loc.serv})。服務可以在TON Blockchain中創建智能合約，為其客戶提供一些保證 (參考~\ptref{sp:mixed.serv})。
\item {\em TON DNS\/} (參考~\ptref{sp:ton.dns})，用於為賬戶、智能合約、服務和網路節點分配易讀的名稱。
\item {\em TON Payments\/} (參考第~\ptref{sect:payments}章)，一個用於微支付、微支付通道和微支付通道網路的平台。它可用於快速的鏈下價值轉移，以及支付由 {\em TON Services} 提供的服務。
\item TON將允許輕鬆集成第三方消息和社交網路應用程序，從而使區塊鏈技術和分散服務終於可用且可被普通使用者訪問 (參考~\ptref{sp:ton.www})，而不僅僅是少數早期的加密貨幣採用者。我們將在我們的另一個專案中，Telegram Messenger (參考~\ptref{sp:telegram.integr})，提供這樣的集成例子。
\end{itemize}

雖然 TON Blockchain 是 TON 專案的核心，而其他組件可能被視為對區塊鏈扮演輔助角色，但它們自身也具有有趣和實用的功能。結合使用，它們允許平台容納比僅使用 TON Blockchain 更多樣化的應用程式 (參考~\ptref{sp:blockchain.facebook} 和~\ptref{sect:ton.service.impl})。

\clearpage
\mysection{TON Blockchain}\label{sect:blockchain}

我們從描述 The Open Network (TON) Blockchain 開始，這是該專案的核心組件。我們這裡的方法是「由上而下」：我們首先給出整體的一般描述，然後提供每個組件的更多細節。

為了簡單起見，我們在此談論 {\em the/} TON Blockchain，即使原則上這種區塊鏈協議可能有多個獨立運行的實例（例如，由於硬分叉的結果）。我們只考慮其中之一。

\mysubsection{TON Blockchain 作為 2-區塊鏈的集合}

TON Blockchain 實際上是區塊鏈的{\em 集合}（甚至是區塊鏈的區塊鏈集合，或稱為{\em 2-區塊鏈}---這一點將在~\ptref{sp:inv.sh.blk.corr}中進一步說明），因為沒有單一的區塊鏈專案能夠達到我們每秒處理數百萬交易的目標，而不是現在的每秒數十次交易的標準。


\nxsubpoint\label{sp:list.blkch.typ}
\embt(List of blockchain types.) 此系列中的區塊鏈包括：
\begin{itemize}
\item 唯一的{\em master blockchain}，或簡稱為{\em masterchain}，該區塊鏈包含有關協議的一般資訊、其參數的當前值、validator集合和他們的股份、當前活躍的工作鏈(workchains)及其"shards"，以及最重要的，所有workchains和shardchains的最近區塊的雜湊集合。
\item 數個(最多 $2^{32}$)的{\em working blockchains}，或簡稱為{\em workchains}，實際上是這系統的"工作馬"，包含價值轉移和智能合約交易。不同的workchains可能有不同的"規則"，意味著帳戶地址的不同格式、交易的不同格式、智能合約的不同虛擬機(VMs)、不同的基本加密貨幣等等。然而，它們都必須滿足某些基本的互操作性標準，以確保不同的workchains之間的互動簡單和可能。在這方面，TON Blockchain是{\em heterogeneous}（參考~\ptref{sp:blkch.hom.het}），類似於EOS（參考~\ptref{sp:discuss.EOS}）和PolkaDot（參考~\ptref{sp:discuss.PolkaDot}）專案。
\item 每個workchain會進一步細分為多達 $2^{60}$ 的{\em shard blockchains}，或簡稱為{\em shardchains}，它們具有與workchain本身相同的規則和區塊格式，但只對帳戶的某個子集負責，這取決於帳戶地址的幾個首位(最重要的位)。換句話說，這系統內建了一種分片(sharding)的形式（參考~\ptref{sp:shard.supp}）。因為所有這些shardchains共享通用的區塊格式和規則，TON Blockchain在這方面是{\em homogeneous}（參考~\ptref{sp:blkch.hom.het}），這與Ethereum的某個擴展建議相似。\footnote{\url{https://github.com/ethereum/wiki/wiki/Sharding-FAQ}}
\item shardchain（和masterchain）中的每個區塊實際上不只是一個區塊，而是一個小區塊鏈。通常，這"block blockchain"或"vertical blockchain"只包含一個區塊，然後我們可能會認為這只是shardchain的相對應區塊（在這種情況下也稱為"horizontal blockchain"）。但是，如果需要修正不正確的shardchain區塊，新的區塊將被提交到"vertical blockchain"，包含無效"horizontal blockchain"區塊的替代品，或一個"block difference"，只包含該區塊先前版本中需要更改的部分的描述。這是一個TON特有的機制，用於替換檢測到的無效區塊，而不會真正地分叉所有涉及的shardchains；這將在~\ptref{sp:inv.sh.blk.corr}中詳細解釋。目前，我們只需指出，每個shardchain（和masterchain）不是一個常規的區塊鏈，而是一個{\em blockchain of blockchains}，或{\em 2D-blockchain}，或只是一個{\em 2-blockchain}。
\end{itemize}

\nxsubpoint\label{sp:ISP} \embt(Infinite Sharding Paradigm.)無限分片範式。 幾乎所有的區塊鏈分片提案都是「自上而下」：首先想像一個單一的區塊鏈，然後討論如何將它分割成幾個互動的分片鏈以提高效能和達到可擴展性。

TON的分片方法是「自下而上」，如下所述。

想像分片已被極端化，以至於每個分片鏈中只剩下一個帳戶或智能合約。然後我們有大量的「帳戶鏈」，每個鏈描述只有一個帳戶的狀態和狀態過渡，並向彼此發送具有價值的消息以傳輸價值和信息。

當然，擁有數億的區塊鏈是不切實際的，每個鏈中的更新（即新的區塊）通常出現得相對較少。為了更有效地實施它們，我們將這些「帳戶鏈」組合成「分片鏈」，以便分片鏈的每個區塊基本上是已分配給此分片的帳戶鏈的區塊的集合。因此，「帳戶鏈」只在「分片鏈」內部擁有純粹的虛擬或邏輯存在。

我們稱這種觀點為「無限分片範式」。它解釋了TON區塊鏈的許多設計決策。

\nxsubpoint\label{sp:msg.IHR} \embt(Messages. Instant Hypercube Routing.)消息。即時超立方路由。 無限分片範式告訴我們將每個帳戶（或智能合約）視為它自己的分片鏈中。然後，一個帳戶可能影響另一帳戶的狀態的唯一方式是向它發送一個「消息」（這是所謂的Actor模型的特殊實例，其中帳戶作為Actors；cf.~\ptref{sp:actors}）。因此，帳戶間（和分片鏈間，因為源帳戶和目的地帳戶，一般來說，位於不同的分片鏈中）的消息系統對於像TON區塊鏈這樣的可擴展系統非常重要。事實上，TON區塊鏈的一個新特性，稱為「即時超立方路由」（cf.~\ptref{sp:instant.hypercube}），使它能夠將消息從一個分片鏈的區塊傳遞和處理到目的地分片鏈的下一個區塊，{\em 不考慮系統中的分片鏈總數。}

\nxsubpoint \embt(Quantity of masterchains, workchains and shardchains.) TON 區塊鏈中恰有一個主鏈(masterchain)。但是，此系統有潛能容納高達 \(2^{32}\) 的工作鏈(workchains)，每個工作鏈都可細分為高達 \(2^{60}\) 的分片鏈(shardchains)。

\nxsubpoint \embt(Workchains can be virtual blockchains, not true blockchains.) 由於工作鏈通常被細分為分片鏈，工作鏈的存在是「虛擬的」，這意味著它不是一個真正的區塊鏈，如~\ptref{sp:gen.blkch.def}下提供的一般定義所描述，而只是一組分片鏈的集合。當只有一個分片鏈對應到一個工作鏈時，這個獨特的分片鏈可能與工作鏈相同，這樣它在某個時間點變成一個「真正的」區塊鏈，進而與常規的單一區塊鏈設計有相似性。然而，無限分片範式 (cf.~\ptref{sp:ISP}) 告訴我們這種相似性確實是表面的：能夠將潛在的大量「帳戶鏈」暫時分組到一個區塊鏈只是一個巧合。

\nxsubpoint \embt(Identification of workchains.) 每一個工作鏈都由其{\em number\/}或{\em workchain identifier\/}（\(\workchainid:\uint_{32}\)）來識別，它只是一個無符號的32位整數。工作鏈是由主鏈中的特殊交易所創建，定義（先前未使用的）工作鏈識別符和工作鏈的正式描述，至少足以讓此工作鏈與其他工作鏈互動以及對此工作鏈的區塊進行表面驗證。

\nxsubpoint \embt(Creation and activation of new workchains.) 新的工作鏈的創建可以由社區中的任何成員啟動，只要他們準備支付發佈新工作鏈的正式規範所需的（高額）主鏈交易費用。但是，為了使新的工作鏈變得活躍，需要三分之二的validator達成共識，因為他們需要升級他們的軟件以處理新工作鏈的區塊，並通過特殊的主鏈交易表示他們準備好與新的工作鏈一起工作。對新工作鏈的啟動感興趣的方可能會提供某些激勵，讓validator透過智能合約分發的某些獎勵來支持新的工作鏈。

\nxsubpoint\label{sp:shard.ident} \embt(Identification of shardchains.) 每個分片鏈(shardchain)都由一對 $(w,s)=(\workchainid, \shardpfx)$ 來識別，其中 $\workchainid:\uint_{32}$ 識別相應的工作鏈(workchain)，而 $\shardpfx:\st2^{0\ldots60}$ 是一個最長為60的位元串，定義此分片鏈所負責的帳戶子集。換句話說，所有以 $\shardpfx$ 開頭的帳戶 $\accountid$ （即，具有 $\shardpfx$ 作為最重要位元）都將被分配到這個分片鏈。

\nxsubpoint \embt(Identification of account-chains.) 回憶一下，帳戶鏈(account-chains)只有虛擬存在 (cf.~\ptref{sp:ISP})。然而，它們有一個自然的識別符——即，$(\workchainid,\accountid)$——因為任何帳戶鏈都包含關於恰好一個帳戶（無論是簡單帳戶還是智能合約——這裡的區別不重要）的狀態和更新的信息。

\nxsubpoint\label{sp:dyn.split.merge} \embt(Dynamic splitting and merging of shardchains; cf.~\ptref{sect:split.merge}.) 一個較不複雜的系統可能使用{\em static sharding}，例如，使用 $\accountid$ 的前八位來選擇256個預定義的碎片之一。

TON 區塊鏈的一個重要特點是它實現了{\em dynamic sharding}，這意味著碎片的數量不是固定的。相反，如果滿足某些正式條件（基本上，如果原始碎片上的交易負載在很長的時間內都足夠高），分片 $(w,s)$ 可以自動細分為分片 $(w,s.0)$ 和 $(w,s.1)$。相反，如果負載在一段時間內保持得太低，分片 $(w,s.0)$ 和 $(w,s.1)$ 可以自動合併回分片 $(w,s)$。

最初，只為工作鏈 $w$ 創建了一個分片 $(w,\emptyset)$。稍後，當這變得必要時，它被細分為更多的分片 (cf.~\ptref{sp:split.necess} and~\ptref{sp:merge.necess})。

\nxsubpoint\label{sp:basic.workchain} \embt(Basic workchain or Workchain Zero.) 雖然可以定義高達 $2^{32}$ 的工作鏈(workchains)並有其特定的規則和交易，但我們一開始只定義一個，即 $\workchainid=0$。這個工作鏈被稱為Workchain Zero或基礎工作鏈，它是用於操作{\em TON smart contracts\/} 和轉移{\em Toncoin}，也稱為{\em Toncoin\/} (cf.\ Appendix~\ref{app:coins})。大多數應用可能只需要Workchain Zero。基礎工作鏈的分片鏈會被稱為{\em basic shardchains}。

\nxsubpoint \embt(Block generation intervals.) 我們預計每個分片鏈和主鏈大約每五秒會生成一個新的區塊。這將導致相對較小的交易確認時間。所有分片鏈的新區塊大約同時生成；主鏈的新區塊大約在一秒後生成，因為它必須包含所有分片鏈的最新區塊的雜湊值。

\nxsubpoint\label{sp:sc.hash.mc} \embt(Using the masterchain to make workchains and shardchains tightly coupled.) 一旦分片鏈的區塊的雜湊值被合併到主鏈的區塊中，該分片鏈區塊及其所有祖先都被認為是「正規的」，這意味著它們可以被所有分片鏈的後續區塊引用為固定且不可變的內容。實際上，每個新的分片鏈區塊都包含最近的主鏈區塊的雜湊值，並且從該主鏈區塊引用的所有分片鏈區塊在新區塊中都被認為是不可變的。

從本質上講，這意味著在分片鏈區塊中提交的交易或消息可以在其他分片鏈的下一個區塊中安全地使用，而不需要等待，例如，二十次確認（即在同一區塊鏈中在原始區塊之後生成的二十個區塊）之前轉發消息或基於之前的交易採取其他操作，這在大多數建議的「鬆散連接」系統中很常見(cf.~\ptref{sp:blkch.interact})，如EOS。我們相信，這種能力在提交後的五秒內在其他分片鏈中使用交易和消息是我們這種「緊密連接」系統能夠提供前所未有的性能的原因之一(cf.~\ptref{sp:shard.supp} and~\ptref{sp:blkch.interact})。

\nxsubpoint \embt(Masterchain block hash as a global state.) 根據~\ptref{sp:sc.hash.mc}，最後一個主鏈區塊的雜湊完全確定了外部觀察者的整體系統狀態。人們不需要單獨監視所有分片鏈的狀態。

\nxsubpoint \embt(Generation of new blocks by validators; cf.~\ptref{sect:validators}.) TON 區塊鏈使用 Proof-of-Stake (PoS) 方法在分片鏈和主鏈中生成新的區塊。這意味著有一組，例如，多達幾百個的{\em validators}---特殊的節點，透過特殊的主鏈交易存放{\em stakes\/}（大量的 Toncoin）以符合生成和驗證新區塊的資格。

然後，小部分的validator被分配給每一個分片 $(w,s)$，這是以決定性的偽隨機方式進行的，每1024個區塊大約會改變一次。這部分的validator建議並在下一個分片鏈區塊應是什麼上達成共識，通過從客戶端收集適當的建議交易到新的有效的區塊候選。對於每個區塊，validator上有一個偽隨機選定的順序，以確定誰的區塊候選在每一輪中有最高的優先順序被提交。

validator和其他節點檢查所提議的區塊候選的有效性；如果validator簽署了一個無效的區塊候選，它可能會自動被懲罰，失去部分或全部的 stake，或被暫停從validator集合一段時間。之後，validator應達成對下一個區塊的選擇的共識，本質上是 BFT (Byzantine Fault Tolerant; cf.~\ptref{sp:dpos.bft}) 共識協議的高效變體，類似於 PBFT~\cite{PBFT} 或 Honey Badger BFT~\cite{HoneyBadger}。如果達到共識，將創建新的區塊，且validator在交易費用上進行分割，包括交易，加上一些新創建的（“鑄造的”）硬幣。

每個validator可以被選舉參與多個validator子集；在這種情況下，預計它將平行運行所有的驗證和共識算法。

在生成所有新的分片鏈區塊之後或超時之後，將生成一個新的主鏈區塊，包括所有分片鏈的最新區塊的雜湊值。這是通過{\em all\/} validator的 BFT 共識完成的。\footnote{實際上，兩個三分之一的 stake 就足夠達成共識，但努力收集盡可能多的簽名。}

TON PoS 方法及其經濟模型的更多細節提供在 section~\ptref{sect:validators}。

\nxsubpoint \embt(Forks of the masterchain.) 我們緊密耦合的方法帶來的一個複雜性是，切換到主鏈的不同分叉幾乎必然需要在至少一些分片鏈中切換到另一個分叉。另一方面，只要主鏈中沒有分叉，分片鏈中的分叉甚至都是不可能的，因為分片鏈的替代分叉中的沒有區塊可以通過將其雜湊值納入主鏈區塊而變得「標準化」。

一般的規則是，{\em 如果主鏈區塊 $B'$ 是 $B$ 的前輩，$B'$ 包括 $(w,s)$-分片鏈區塊 $B'_{w,s}$ 的雜湊 $\Hash(B'_{w,s})$，且 $B$ 包括雜湊 $\Hash(B_{w,s})$，那麼 $B'_{w,s}$ {\bf 必須}是 $B_{w,s}$ 的前輩; 否則，主鏈區塊 $B$ 就是無效的。}

我們預期主鏈分叉將會很少，幾乎不存在，因為在由 TON 區塊鏈所採用的 BFT 範疇中，它們只能在{\em 大部分\/} validator行為不正確的情況下發生（參見~\ptref{sp:validators} 和~\ptref{sp:new.master.blk}），這將意味著由違反者承擔的重大的 stake 損失。因此，不應期待分片鏈中存在真正的分叉。相反，如果檢測到一個無效的分片鏈區塊，將通過 2-blockchain 的「垂直區塊鏈」機制進行修正（參見~\ptref{sp:inv.sh.blk.corr}），這可以在不分叉「水平區塊鏈」（即，分片鏈）的情況下實現此目標。同樣的機制也可以用來修正主鏈區塊中的非致命性錯誤。

\nxsubpoint\label{sp:inv.sh.blk.corr} \embt(Correcting invalid shardchain blocks.) 通常，只有有效的分片鏈區塊會被提交，因為分配給分片鏈的validator在新區塊可以被提交之前必須達到三分之二的拜占庭共識。然而，系統必須允許檢測先前提交的無效區塊及其校正。

當然，一旦找到一個無效的分片鏈區塊 —— 不論是由一個validator（不一定分配到這個分片鏈）還是一個「fisherman」（系統的任何節點，它已經支付了某個存款以便對區塊有效性提出疑問；參見~\ptref{sp:fish}）—— 無效性的主張及其證明都會被提交到主鏈，而已經簽署無效區塊的validator將被懲罰，部分或全部扣除他們的 stake，和/或暫時從validator集合中被停權（後者的措施對於攻擊者竊取本質上良性的validator的私有簽名鍵非常重要）。

然而，這還不夠，因為由於先前提交的無效分片鏈區塊，系統（TON 區塊鏈）的整體狀態結果是無效的。這個無效區塊必須被一個新的有效版本替換。

大多數系統會通過「回滾」到該分片鏈中的無效區塊之前的最後一個區塊，以及每個其他分片鏈中不受從無效區塊傳播的消息影響的最後區塊，並從這些區塊創建一個新的分叉來實現這一點。這種方法的缺點是，大量本來正確且已提交的交易突然被回滾，且不清楚它們是否會在稍後再次被包括。

TON 區塊鏈通過使每個分片鏈和主鏈的每個「區塊」（「水平區塊鏈」）本身都成為一個小型區塊鏈（「垂直區塊鏈」），包含這個「區塊」的不同版本，或其「差異」來解決這個問題。通常，垂直區塊鏈只包含一個區塊，而分片鏈看起來像一個經典的區塊鏈。但是，一旦一個區塊的無效性被確認並提交到主鏈區塊中，該無效區塊的「垂直區塊鏈」就被允許在垂直方向上增加一個新區塊，替換或編輯無效區塊。這個新區塊是由當前問題分片鏈的validator子集生成的。


新的“垂直”區塊要有效的規則非常嚴格。特別是，如果無效區塊中包含的虛擬“帳戶鏈區塊”（參見 \ptref{sp:ISP}）本身是有效的，則它必須被新的垂直區塊保持不變。

一旦在無效區塊上方提交了新的“垂直”區塊，它的雜湊就會在新的Masterchain區塊中公布（或者更正確地說，在原始Masterchain區塊上方的新“垂直”區塊中公布，該區塊中最初發布了無效Shardchain區塊的雜湊），並且進一步將更改傳播到任何參照此區塊的Shardchain區塊（例如，那些從不正確的區塊接收消息的區塊）。這可以通過在先前參照“不正確”區塊的所有區塊的垂直區塊鏈中提交新的“垂直”區塊來進行修正；新的垂直區塊將參照最新（已更正）的版本。同樣，嚴格的規則禁止更改未受到實際影響的帳戶鏈（即，與前一版本中收到的消息相同的帳戶鏈）。通過這種方式，修正不正確的區塊產生“漣漪”，最終傳播到所有受影響的Shardchain的最新區塊；這些更改也反映在新的“垂直”Masterchain區塊中。

一旦“歷史重寫”的漣漪到達最新區塊，新的Shardchain區塊僅以一個版本生成，僅作為最新區塊版本的後繼者。這意味著它們將從一開始就包含對正確（最新）的垂直區塊的引用。

Masterchain狀態隱含地定義了一個映射，將每個“垂直”區塊鏈的第一個區塊的雜湊轉換為其最新版本的雜湊。這使客戶端可以通過其第一個（通常是唯一的）區塊的雜湊識別和定位任何垂直區塊鏈。

\nxsubpoint \embt(Toncoin and multi-currency workchains.)  TON區塊鏈支持多達$2^{32}$種不同的“加密貨幣”、“硬幣”或“代幣”，通過32位的$\currencyid$加以區分。新的加密貨幣可以通過主鏈中的特殊交易來添加。每個工作鏈都有一種基本加密貨幣，並且可以有幾種其他加密貨幣。

有一種特殊的加密貨幣，$\currencyid=0$，即{\em TON幣}，也稱為{\em Toncoin}（參見附錄~\ref{app:coins}）。這是工作鏈零的基本加密貨幣。它也用於交易費和validator的權益股份。

原則上，其他工作鏈可能會以其他代幣收取交易費。在這種情況下，應該提供一些智能合約，用於將這些交易費自動轉換為Toncoin。

\nxsubpoint \embt(Messaging and value transfer.) 屬於相同或不同工作鏈的分片鏈可以互相傳送{\em messages\/}。儘管允許的訊息的確切形式取決於接收工作鏈和接收帳戶（智能合約），但有一些共同的欄位使跨工作鏈的訊息成為可能。特別是，每條訊息可能會有一些{\em value}，以一定數量的Toncoin（Toncoin）和/或其他註冊的加密貨幣的形式附加，前提是它們被接收工作鏈宣布為可接受的加密貨幣。

這種訊息的最簡單形式是從一個（通常不是智能合約）帳戶到另一個帳戶的價值轉移。

\nxsubpoint\label{sp:tonvm} \embt(TON Virtual Machine.)  {\em TON Virtual Machine}，也縮寫為{\em TON VM\/}或{\em TVM\/}，是用於在主鏈和基本工作鏈中執行智能合約程式碼的虛擬機器。其他工作鏈可能使用其他虛擬機器，與TVM一起或替代TVM。

以下我們列出了其一些特性。它們在~\ptref{sp:pec.tvm}、\ptref{sp:tvm.cells}和其他地方進一步討論。

\begin{itemize}
\item TVM 將所有資料表示為一系列的{\em (TVM) cells/} (參考~\ptref{sp:tvm.cells})。每一個 cell 包含最多 128 個資料位元組，以及最多 4 個指向其他 cells 的參考。基於“一切皆為 cell 包”的理念 (參考~\ptref{sp:everything.is.BoC})，這使得 TVM 能夠處理與 TON 區塊鏈相關的所有資料，包括必要時的區塊和區塊鏈全域狀態。
\item TVM 可以處理任意代數資料型態的值 (參考~\ptref{sp:pec.tvm})，表示為 TVM cells 的樹或有向非循環圖。但它對代數資料型態的存在是不知情的；它只是處理 cells。
\item TVM 內建支援 hashmaps (參考~\ptref{sp:patricia})。
\item TVM 是一個堆疊機器。它的堆疊保存 64 位元整數或 cell 參考。
\item 支援 64-bit, 128-bit 和 256-bit 的算術運算。所有 $n$-bit 的算術操作都有三種形式：用於無符號整數，用於有符號整數，以及對於模 $2^n$ 的整數（後者不自動檢查溢出）。
\item TVM 有從 $n$-bit 轉換到 $m$-bit 的無符號和有符號整數，對所有 $0\leq m,n\leq 256$，並具有溢出檢查。
\item 所有算術操作預設執行溢出檢查，這大大簡化了智能合約的開發。
\item TVM 有“乘然後移位”和“移位然後除”的算術操作，中間值在更大的整數型態中計算；這簡化了固定點算術的實現。
\item TVM 提供對位串和字節串的支援。
\item 提供對某些預定義曲線，包括 Curve25519 的 256-bit 橢圓曲線加密 (ECC) 的支援。
\item 對於在某些橢圓曲線上的 Weil 配對的支援也存在，這對於快速實現 zk-SNARKs 很有用。
\item 支援包括 $\Sha$ 在內的流行雜湊函數。
\item TVM 可以處理 Merkle 證明 (參考~\ptref{sp:ton.smart.pc.supp})。
\item TVM 提供對“大型”或“全域”智能合約的支援。這類智能合約必須知道分片 (參考~\ptref{sp:loc.glob.smct} 和 \ptref{sp:tvm.data.shard})。常規（本地）智能合約可以是不知道分片的。
\item TVM 支援閉包。
\item 一個“無脊標籤 $G$-機器” \cite{STGM} 可以容易地在 TVM 內部實現。
\end{itemize}
除了“TVM 組件”，還可以為 TVM 設計幾種高級語言。所有這些語言都將具有靜態類型，並支援代數資料型態。我們預見以下可能性：
\begin{itemize}
\item 類似 Java 的命令式語言，每個智能合約都像一個獨立的類。
\item 惰性的功能語言 (如 Haskell)。
\item 積極的功能語言 (如 ML)。
\end{itemize}
 
\nxsubpoint\label{sp:config.param} \embt(Configurable parameters.) 
TON Block\-chain 的一個重要特性是它有許多{\em 可配置的}參數。這意味著它們是 masterchain 狀態的一部分，且可以通過 masterchain 中的某些特殊的提議/投票/結果交易來更改，而不需要硬分叉。更改這些參數需要收集三分之二的validator投票，以及超過一半想要參與投票過程的所有其他參與者的投票以支持該提議。

\mysubsection{關於區塊鏈的概論}

\nxsubpoint\label{sp:gen.blkch.def} \embt(General blockchain definition.) 
一般來說，任何{\em (真實的) 區塊鏈\/}都是一系列的{\em 區塊}，每個區塊 \(B\) 都包含一個參考至前一個區塊的 $\blkprev(B)$ （通常是將前一個區塊的雜湊包含在當前區塊的標頭中），以及一個{\em 交易}的列表。每筆交易都描述了{\em 全域區塊鏈狀態}的某種轉換; 一個區塊中列出的交易是按順序應用的，從舊狀態開始計算新狀態，這是在評估前一個區塊後的結果狀態。

\nxsubpoint \embt(Relevance for the TON Blockchain.) 
請注意，{\em TON Block\-chain\/} 並不是真正的區塊鏈，而是 2-區塊鏈的集合（即，區塊鏈的區塊鏈集合; 參考~\ptref{sp:list.blkch.typ}），所以上述內容並不直接適用於它。然而，我們從真正的區塊鏈的這些一般性開始，用它們作為我們更複雜建構的基礎。

\nxsubpoint \embt(Blockchain instance and blockchain type.)  人們經常使用「{\em blockchain\/}」一詞來表示一般的{\em blockchain type\/} 和其特定的 {\em blockchain instances}，定義為滿足某些條件的區塊序列。例如，\ptref{sp:gen.blkch.def} 是指區塊鏈的實例。

由此，一個區塊鏈類型通常是類型 $\Block^*$ 的「子類型」，由那些滿足某些相容性和有效性條件的區塊序列組成：
\begin{equation}
  \Blockchain \subset \Block^*
\end{equation}

更好的定義方式是說 $\Blockchain$ 是一個{\em dependent couple type}，由 couple $(\bbB,v)$組成，第一部分 $\bbB:\Block^*$ 是類型 $\Block^*$（即區塊列表），第二部分 $v:\isValidBc(\bbB)$ 是 $\bbB$ 的有效性的證明或證人。由此，
\begin{equation}
  \Blockchain\equiv\Sigma_{(\bbB:\Block^*)}\isValidBc(\bbB)
\end{equation}
我們在這裡使用了從~\cite{HoTT} 借用的依賴型態和的表示法。

\nxsubpoint \embt(Dependent type theory, Coq and TL.)  注意，我們在此使用的是（Martin-L\"of）依賴型態理論，類似於 Coq\footnote{\url{https://coq.inria.fr}} 證明助手中使用的。依賴型態理論的簡化版本也用於{\em TL (Type
  Language)}\footnote{\url{https://core.telegram.org/mtproto/TL}}，將在 TON Blockchain 的正式規範中使用，描述所有資料結構的序列化以及區塊、交易等的佈局。

事實上，依賴型態理論提供了對證明是什麼的有用形式化。當需要提供某個區塊的無效性證明時，這種形式的證明（或它們的序列化）可能會變得很有用。

\nxsubpoint\label{sp:TL} \embt(TL, or the Type Language.)  由於 TL（Type Language）將被用於 TON 區塊、交易和網路數據包的正式規範，因此值得簡短地討論。

TL 是一種適用於描述依賴代數的{\em types}的語言，允許具有數字（自然數）和型態參數。每個型態都通過幾個{\em constructors}來描述。每個構造器都有一個（人類可讀的）識別碼和一個{\em name}，這是一個位元組列（預設為32位整數）。除此之外，構造器的定義包含一個與其型態一起的字段列表。

構造器和型態定義的集合被稱為{\em TL-scheme}。它通常保存在一個或多個帶有 \texttt{.tl} 後綴的文件中。

TL-schemes 的一個重要特性是，它們確定了序列化和反序列化定義的代數型態的值（或對象）的明確方式。具體來說，當一個值需要被序列化為一串位元組時，首先序列化用於此值的構造器的名稱。然後是每個字段的遞迴計算的序列化。

一個適合序列化任意對象為 32 位整數序列的 TL 的先前版本的描述，可以在 \url{https://core.telegram.org/mtproto/TL} 上找到。一個新版本的 TL，名為 {\em TL-B}，正在開發中，用於描述 TON Project 使用的對象的序列化。這個新版本可以將對象序列化為位元組流，甚至是位元流（而不僅僅是32位整數），並提供將其序列化為 TVM cell 樹的支持（cf.~\ptref{sp:tvm.cells}）。TL-B 的描述將是 TON Blockchain 的正式規範的一部分。



\nxsubpoint\label{sp:blk.transf} \embt(Blocks and transactions as
state transformation operators.) 通常，任何區塊鏈(型態)
$\Blockchain$ 都有一個關聯的全域狀態(型態) $\State$，以及一個
交易(型態) $\Transaction$。區塊鏈的語意在很大程度上是由交易應用函數所決定的：
\begin{equation}
  \evtrans':\Transaction\times\State\to\State^?
\end{equation}
這裡的 $X^?$ 表示 $\Maybe X$，是將 $\Maybe$ 單子應用於型態 $X$ 的結果。這與我們使用 $X^*$ 表示 $\List
X$ 類似。本質上，型態 $X^?$ 的值要麼是型態 $X$ 的值，要麼是一個特殊值 $\bot$ 表示實際值的缺失
(想想空指標)。在我們的情境中，我們使用 $\State^?$ 而不是 $\State$ 作為結果型態，因為某個交易從某些原始狀態
呼叫可能是無效的 (想想從賬戶中提款的金額超過實際存在的金額的情況)。

我們可能更偏好 $\evtrans'$ 的柯里化版本：
\begin{equation}
  \evtrans:\Transaction\to\State\to\State^?
\end{equation}

因為一個區塊本質上是交易的列表，所以區塊的評估函數
\begin{equation}
  \evblock:\Block\to\State\to\State^?
\end{equation}
可以從 $\evtrans$ 中衍生出來。它接受一個區塊 $B:\Block$ 和前一個區塊鏈狀態 $s:\State$ (可能包括前一個區塊的雜湊) 並計算下一個區塊鏈狀態
$s'=\evblock(B)(s):\State$，它要么是一個真正的狀態，要么是一個特殊值 $\bot$ 表示下一狀態無法被計算 (也就是說，從給定的起始狀態評估時該區塊是無效的——例如，該區塊包含試圖從一個空帳戶扣款的交易)。

\nxsubpoint \embt(Block sequence numbers.) 每個在區塊鏈中的區塊 $B$
可以由其{\em 序列號} $\blkseqno(B)$ 來參照，從第一個區塊開始為零，並在過渡到下一個區塊時加一。更正式地說，
\begin{equation}
  \blkseqno(B)=\blkseqno\bigl(\blkprev(B)\bigr)+1
\end{equation}
請注意，序列號在有{\em 分叉}的情況下不能唯一識別一個區塊。

\nxsubpoint \embt(Block hashes.) 參考區塊 $B$ 的另一種方式是通過其雜湊 $\blkhash(B)$，其實際上是區塊 $B$ 的
            {\em 頭部\/}的雜湊（但是，區塊的頭部通常包含依賴於區塊 $B$ 的所有內容的雜湊）。假設所使用的雜湊函數沒有碰撞（或至少它們是非常不可能的），一個區塊可以由其雜湊唯一識別。

\nxsubpoint \embt(Hash assumption.) 在對區塊鏈算法進行正式分析時，我們假設使用的 $k$-bit 雜湊函數 $\Hash:\Bytes^*\to\st2^{k}$ 沒有碰撞：
\begin{equation}\label{eq:hash.coll}
  \Hash(s)=\Hash(s')\Rightarrow s=s'\quad\text{對任何 $s$,
    $s'\in\Bytes^*$}
\end{equation}
這裡的 $\Bytes=\{0\ldots255\}=\st2^8$ 是位元組的類型，或所有位元組值的集合，而 $\Bytes^*$ 是任意（有限）位元組列表的類型或集合；而 $\st2=\{0,1\}$ 是位元類型，和 $\st2^k$ 是所有 $k$-bit 序列的集合（即，$k$-bit 數字）。

當然，\eqref{eq:hash.coll} 在數學上是不可能的，因為從一個無窮集合到一個有限集合的映射不能是單射。一個更嚴格的假設是
\begin{equation}\label{eq:hash.coll.prec}
  \forall s, s': s\neq s', P\bigl(\Hash(s)=\Hash(s')\bigr)=2^{-k}
\end{equation}
然而，這對於證明不太方便。如果在某個小的 $\epsilon$（例如，$\epsilon=10^{-18}$）的證明中\eqref{eq:hash.coll.prec} 至多使用了 $N$ 次，其中 $2^{-k}N<\epsilon$，我們可以像 \eqref{eq:hash.coll} 是真的那樣推理，只要我們接受失敗概率 $\epsilon$（即，最終的結論至少以概率 $1-\epsilon$ 為真）。

最後的備註：為了使~\eqref{eq:hash.coll.prec} 的概率說明真正嚴格，必須在所有位元組序列的集合 $\Bytes^*$ 上引入一個概率分佈。做到這一點的一種方法是假設相同長度 $l$ 的所有位元組序列都是等概率的，並設置觀察到長度為 $l$ 的序列的概率等於 $p^l-p^{l+1}$，對於某些 $p\to1-$。然後應該將\eqref{eq:hash.coll.prec} 理解為當 $p$ 從下面趨近於一時的條件概率 $P\bigl(\Hash(s)=\Hash(s')|s\neq s'\bigr)$ 的極限。

\nxsubpoint\label{sp:hash.change} \embt(Hash used for the TON
Blockchain.) 我們目前為TON Blockchain使用256-bit的$\Sha$雜湊。如果它被證明比預期弱，未來可以被另一個雜湊函數所取代。雜湊函數的選擇是協議的可配置參數，所以可以在~\ptref{sp:config.param}中解釋的，無需硬分叉即可更改。

\mysubsection{區塊鏈狀態、帳戶和雜湊映射}

如上所述，任何區塊鏈都定義了某種全域狀態，且每個區塊和每個交易都定義了這個全域狀態的轉換。在此我們描述由TON區塊鏈使用的全域狀態。

\nxsubpoint \embt(Account IDs.) TON區塊鏈使用的基本帳戶ID──或者至少由其主鏈和工作鏈零所使用──是256-bit整數，假設是針對特定橢圓曲線的256-bit橢圓曲線密碼學(ECC)的公鑰。這樣，
\begin{equation}
  \accountid:\Account=\uint_{256}=\st2^{256}
\end{equation}
這裡的$\Account$是帳戶的{\em 類型}，而$\accountid:\Account$是類型$\Account$的特定變量。

其他工作鏈可以使用其他帳戶ID格式，無論是256-bit還是其他格式。例如，可以使用等於ECC公鑰的$\Sha$的比特幣風格的帳戶ID。

但是，帳戶ID的位長度$l$必須在工作鏈的創建期間（在主鏈中）固定，且必須至少為64，因為$\accountid$的前64位用於分片和訊息路由。

\nxsubpoint \embt(Main component: {\em Hashmaps}.) TON區塊鏈狀態的主要組件是一個{\em 雜湊映射}。在某些情況下，我們考慮（部分定義的）``映射'' $h:\st2^n\dashrightarrow\st2^m$。更一般地說，我們可能對於複合類型$X$的雜湊映射$h:\st2^n\dashrightarrow X$感興趣。但是，源（或索引）類型幾乎總是$\st2^n$。

有時，我們有一個``預設值'' $\vr{empty}:X$，且雜湊映射$h:\st2^n\to X$由其``預設值'' $i\mapsto\vr{empty}$「初始化」。

\nxsubpoint \embt(Example: TON account balances.) 一個重要的例子是TON帳戶餘額。它是一個雜湊映射
\begin{equation}
  \vr{balance}:\Account\to\uint_{128}
\end{equation}
將 $\Account=\st2^{256}$ 映射為類型為 $\uint_{128}=\st2^{128}$ 的Toncoin (TON幣) 餘額。此雜湊映射的預設值為零，這意味著最初（在處理第一個區塊之前）所有帳戶的餘額都是零。

\nxsubpoint \embt(Example: smart-contract persistent storage.) 另一個例子是智能合約的持久儲存，可以（非常大致地）表示為一個雜湊映射
\begin{equation}
  \vr{storage}:\st2^{256}\dashrightarrow\st2^{256}
\end{equation}
此雜湊映射的預設值也為零，這意味著未初始化的持久儲存cells被認為是零。

\nxsubpoint \embt(Example: persistent storage of all smart contracts.) 因為我們有多於一個的智能合約，由 $\accountid$ 區分，每個合約都有其獨立的持久儲存，所以我們實際上必須有一個雜湊映射
\begin{equation}
  \vr{Storage}:\Account\dashrightarrow(\st2^{256}\dashrightarrow\st2^{256})
\end{equation}
將智能合約的 $\accountid$ 映射到其持久儲存。

\nxsubpoint \embt(Hashmap type.) 雜湊映射不僅僅是一個抽象的（部分定義的）函數 $\st2^n\dashrightarrow X$；它具有特定的表示方式。因此，我們假設我們有一個特殊的雜湊映射類型
\begin{equation}
  \Hashmap (n,X):\Type
\end{equation}
對應於編碼（部分）映射 $\st2^n\dashrightarrow X$ 的資料結構。我們也可以寫作
\begin{equation}
  \Hashmap (n:\nat) (X:\Type) : \Type
\end{equation}
或
\begin{equation}
  \Hashmap:\nat\to\Type\to\Type
\end{equation}
我們總是可以將 $h:\Hashmap(n,X)$ 轉換為一個映射 $\hget(h):\st2^n\to X^?$。從此，我們通常寫作 $h[i]$ 而非 $\hget(h)(i)$:
\begin{equation}
  h[i]:\equiv\hget(h)(i):X^?\quad\text{對於任何 $i:\st2^n$, $h:\Hashmap(n,X)$}
\end{equation}

\nxsubpoint\label{sp:patricia} \embt(Definition of hashmap type as a Patricia tree.) 從邏輯上講，我們可能會定義 $\Hashmap(n,X)$ 為一個深度為 $n$ 的（不完整的）二進制樹，其邊的標籤為 $0$ 和 $1$，而葉子中的值類型為 $X$。描述相同結構的另一種方式是作為長度等於 $n$ 的二進制字符串的{\em (按位) trie\/}。

在實際應用中，我們更傾向於使用這種 trie 的緊湊表示，通過壓縮每個只有一個子節點的頂點及其父節點。得到的表示稱為 {\em Patricia tree\/} 或 {\em binary radix tree\/}。每個中間頂點現在都有確切的兩個子節點，由兩個非空的二進制字符串標記，左子節點開始為零，右子節點開始為一。

換句話說，在 Patricia 樹中有兩種類型的（非根）節點：
\begin{itemize}
\item $\leaf(x)$，包含類型為 $X$ 的值 $x$。
\item $\node(l,s_l,r,s_r)$，其中 $l$ 是左子節點或子樹的（引用），$s_l$ 是連接此頂點到其左子節點的邊的位字符串標籤（始終以 0 開頭），$r$ 是右子樹，$s_r$ 是到右子節點的邊的位字符串標籤（始終以 1 開頭）。
\end{itemize}
還需要第三種節點類型，只在 Patricia 樹的根上使用一次：
\begin{itemize}
\item $\root(n,s_0,t)$，其中 $n$ 是 $\Hashmap(n,X)$ 的索引位字符串的公共長度，$s_0$ 是所有索引位字符串的公共前綴，$t$ 是指向 $\leaf$ 或 $\node$ 的引用。
\end{itemize}
如果我們想允許 Patricia 樹為空，則會使用第四種類型的（根）節點：
\begin{itemize}
\item $\emptyroot(n)$，其中 $n$ 是所有索引位字符串的公共長度。
\end{itemize}

我們通過以下方式定義 Patricia 樹的高度：
\begin{align}
  \height(\leaf(x))&=0\\ \height\bigl(\node(l,s_l,r,s_r)\bigr)&=\height(l)+\len(s_l)=\height(r)+\len(s_r)\\ \height\bigl(\root(n,s_0,t)\bigr)&=\len(s_0)+\height(t)=n
\end{align}
最後兩個公式中的最後兩個表達式必須相等。我們使用高度為 $n$ 的 Patricia 樹來表示類型為 $\Hashmap(n,X)$ 的值。

如果樹中有 $N$ 個葉子（即，我們的雜湊映射包含 $N$ 個值），則確切有 $N-1$ 個中間頂點。插入一個新值總是涉及通過在中間插入一個新頂點來分割一個現有的邊，並添加一個新葉子作為這個新頂點的另一個子節點。從雜湊映射中刪除一個值做的恰恰相反：葉子和它的父節點被刪除，並且父節點的父節點和其另一個子節點直接連接。

\nxsubpoint\label{sp:merkle.patr.hash} \embt(Merkle-Patricia trees.) 當使用區塊鏈時，我們希望能夠比較 Patricia 樹（即，雜湊映射）及其子樹，並將它們縮減為單一的雜湊值。實現此目的的經典方法是由 Merkle 樹給出的。本質上，我們希望描述一種利用雜湊函數 $\Hash$（為二進制字符串定義）對類型為 $\Hashmap(n,X)$ 的對象 $h$ 進行雜湊的方法，只要我們知道如何計算對象 $x:X$ 的雜湊 $\Hash(x)$ （例如，通過將雜湊函數 $\Hash$ 應用於對象 $x$ 的二進制序列化）。

我們可能會如下遞迴地定義 $\Hash(h)$：
\begin{align}\label{eq:hash.leaf}
  \Hash\bigl(\leaf(x)\bigr):=&\Hash(x)\\
  \label{eq:hash.node}
  \Hash\bigl(\node(l,s_l,r,s_r)\bigr):=&\Hash\bigl(\Hash(l).\Hash(r).\code(s_l).\code(s_r)\bigr)\\ \Hash\bigl(\root(n,s_0,t)\bigr):=&\Hash\bigl(\code(n).\code(s_0).\Hash(t)\bigr)
\end{align}
在此，$s.t$ 表示 (位) 字符串 $s$ 和 $t$ 的連接，而 $\code(s)$ 是所有位字符串 $s$ 的前綴碼。例如，可以通過 10 來編碼 0，通過 11 來編碼 1，並通過 0 來編碼字符串的結尾。%
\footnote{可以證明對於大約一半的 Patricia 樹的邊標籤（具有隨機或連續索引）來說，這種編碼是最優的。其餘的邊標籤可能會很長（即，幾乎有 256 位）。因此，邊標籤的幾乎最優編碼是使用上述碼，對於「短」位字符串使用前綴 0，然後編碼 1，然後是包含位字符串 $s$ 的長度 $l=|s|$ 的九位，然後是 $s$ 的 $l$ 位，用於「長」位字符串（其中 $l\geq10$）。}

我們稍後會看到（參見 \ptref{sp:pec.tvm} 和 \ptref{sp:tvm.cells}），這是針對任意（依賴型）代數類型的值的遞迴定義的雜湊的（稍微調整的）版本。

\nxsubpoint \embt(Recomputing Merkle tree hashes.) 這種遞迴定義 $\Hash(h)$ 的方法，稱為 {\em Merkle tree hash}，具有以下優點：如果與每個節點 $h'$ 一起明確儲存 $\Hash(h')$（結果在結構上被稱為 {\em Merkle tree}，或在我們的情況下，稱為 {\em Merkle--Patricia tree}），則當元素被添加到雜湊映射、從雜湊映射中刪除或在雜湊映射中更改時，最多只需要重新計算 $n$ 個雜湊。

因此，如果將全域區塊鏈狀態表示為適當的 Merkle 樹雜湊，則在每次交易後，重新計算此狀態雜湊就變得很容易。

\nxsubpoint\label{sp:merkle.proof} \embt(Merkle proofs.) 根據所選雜湊函數 $\Hash$ 的「單射性」假設 \eqref{eq:hash.coll}，可以構造一個證明，對於 geven 值 $z$ 的 $\Hash(h)$, $h:\Hashmap(n,X)$, 存在某些 $i:\st2^n$ 和 $x:X$ 使得 $\hget(h)(i)=x$。這樣的證明將包括從對應於 $i$ 的葉子到根的 Merkle--Patricia 樹中的路徑，由此路徑上出現的所有節點的所有兄弟的雜湊增強。

這樣，一個輕量節點%
\footnote{「輕量節點」不跟踪 shardchain 的完整狀態；相反，它保留最小的資訊，例如幾個最近的區塊的雜湊，並在需要檢查完整狀態的某些部分時依賴於從完整節點獲得的資訊。} %
只知道某些 hashmap $h$ 的 $\Hash(h)$ 值（例如，智能合約的持久儲存或全域區塊鏈狀態）可能會從完整節點%
\footnote{「完整節點」是跟踪有關 shardchain 的完整最新狀態的節點。} %
請求不僅僅是值 $x=h[i]=\hget(h)(i)$，而是伴隨著從已知值 $\Hash(h)$ 開始的 Merkle 證明的這樣一個值。然後，在假設 \eqref{eq:hash.coll} 下，輕量節點可以自己檢查 $x$ 確實是 $h[i]$ 的正確值。

在某些情況下，客戶端可能希望獲得值 $y=\Hash(x)=\Hash(h[i])$，例如，如果 $x$ 本身非常大（例如，是一個 hashmap）。然後，可以提供 $(i,y)$ 的 Merkle 證明。如果 $x$ 也是一個 hashmap，那麼可以從完整節點獲得從 $y=\Hash(x)$ 開始的第二個 Merkle 證明，以提供值 $x[j]=h[i][j]$ 或僅其雜湊。

\nxsubpoint \embt(Importance of Merkle proofs for a multi-chain system such as TON.) 請注意，節點通常不能為 TON 環境中存在的所有 shardchains 成為完整節點。它通常只是某些 shardchains 的完整節點——例如，包含其自己的帳戶，它感興趣的智能合約，或者該節點已被指派為其validator的那些。對於其他 shardchains，它必須是一個輕量節點——否則儲存、計算和網路帶寬的要求將是禁止的。這意味著這樣的節點不能直接檢查關於其他 shardchains 狀態的斷言；它必須依賴於從那些 shardchains 的完整節點獲得的 Merkle 證明，除非 \eqref{eq:hash.coll} 失敗（即，找到一個雜湊碰撞），這同樣安全。


\nxsubpoint\label{sp:pec.tvm} \embt(Peculiarities of TON VM.) TON VM 或 TVM (Telegram Virtual Machine)，用於在 masterchain 和 Workchain Zero 中運行智能合約，與受到 EVM (Ethereum Virtual Machine) 啟發的常見設計有很大的不同：它不僅僅與 256 位整數工作，實際上它與（幾乎）任意的「紀錄」、「結構」或「總乘積類型」一起工作，使其更適合執行用高級（尤其是功能性）語言編寫的程式碼。實際上，TVM 使用的是帶有標籤的數據類型，這與 Prolog 或 Erlang 的實現中使用的不太相同。

人們首先可以想像，TVM 智能合約的狀態不僅僅是一個 hashmap $\st2^{256}\to\st2^{256}$ 或 $\Hashmap(256,\st2^{256})$，但（作為第一步）是 $\Hashmap(256,X)$，其中 $X$ 是具有幾個構造器的類型，使其除了 256 位整數之外，還能儲存其他數據結構，尤其是其他的 hashmap $\Hashmap(256,X)$。這意味著 TVM（持久或臨時）儲存的一個cells——或者一個在 TVM 智能合約程式碼中的變量或數組元素——可能不僅包含一個整數，還包含一個全新的 hashmap。當然，這意味著一個cells不僅僅包含 256 位，還包含，例如，一個 8 位的標籤，描述如何解釋這 256 位。

事實上，值不需要確切地是 256 位的。TVM 使用的值格式由原始字節和對其他結構的引用組成，這些引用以任意順序混合，並在合適的位置插入一些描述字節，以便能夠區分指針和原始數據（例如，字符串或整數）；請參見~\ptref{sp:tvm.cells}。

這種原始值格式可以用來實現任意的總乘積代數類型。在這種情況下，該值首先包含一個原始字節，描述正在使用的「構造器」（從高級語言的角度看），然後是其他「字段」或「構造器參數」，由原始字節和對其他結構的引用組成，具體取決於選擇的構造器（參考~\ptref{sp:TL}）。然而，TVM 並不知道構造器及其參數之間的對應關係；字節和引用的混合由某些描述字節明確描述。\footnote{這兩個描述字節，在任何 TVM cells中都存在，僅描述參考總數和原始字節總數；參考總是放在所有原始字節之前或之後。}

Merkle 樹雜湊被擴展到任意這樣的結構：要計算這樣一個結構的雜湊，所有的參考都被遞歸地替換為被參考對象的雜湊，然後計算結果字節串（包括描述字節）的雜湊。

通過這種方式，對 hashmaps 的 Merkle 樹雜湊，如~\ptref{sp:merkle.patr.hash}所述，只是用於類型 $\Hashmap(n,X)$ 的兩個構造器的任意（依賴的）代數數據類型的雜湊的特殊情況。\footnote{實際上，$\leaf$ 和 $\node$ 是輔助類型 $\tp{HashmapAux}(n,X)$ 的構造器。類型 $\Hashmap(n,X)$ 有構造器 $\root$ 和 $\emptyroot$，其中 $\root$ 包含類型 $\tp{HashmapAux}(n,X)$ 的值。}

\nxsubpoint \embt(Persistent storage of TON smart contracts.)
TON 智能合約的持久性儲存主要由其「全域變數」組成，這些變數在調用智能合約之間保持不變。因此，它只是一個「產品」、「元組」或「記錄」類型，由相應於每一個全域變數的正確類型的字段組成。如果全域變數太多，由於 TON cells大小的全域限制，它們不能放入一個 TON cells。在這種情況下，它們被分割成幾個記錄並組織成一棵樹，基本上變成了「產品的產品」或「產品的產品的產品」類型，而不僅僅是一個產品類型。

\nxsubpoint\label{sp:tvm.cells} \embt(TVM Cells.)  最終，TON VM 在一系列的{\em (TVM) cells}中保留所有數據。每個cells首先包含兩個描述符字節，表示此cells中有多少原始數據字節（最多 128）以及有多少對其他cells的引用（最多四個）。然後是這些原始數據字節和引用。每個cells只被引用一次，所以我們可能已經在每個cells中包括了對其「父級」的引用（唯一引用此cells的cells）。但是，這個引用不必是明確的。

通過這種方式，TON 智能合約的持久數據儲存cells被組織成一棵樹，\footnote{邏輯上；在~\ptref{sp:bag.of.cells}中描述的「bag of cells」表示法識別所有重複的cells，當序列化時，將此樹轉換為一個有向無環圖（dag）。} 智能合約描述中保留了對這棵樹的根的引用。如果需要，可以遞歸計算這整個持久儲存的 Merkle 樹雜湊，從葉子開始，然後簡單地將一個cells中的所有引用替換為所引用的cells的遞歸計算的雜湊，然後計算所得字節串的雜湊。

\nxsubpoint\label{sp:gen.merkle.proof} \embt(Generalized Merkle proofs
for values of arbitrary algebraic types.)  由於 TON VM 通過由 (TVM) cells組成的樹來表示任意代數類型的值，且每個cells都有一個明確定義的（遞歸計算的）Merkle 雜湊，實際上依賴於此cells為根的整個子樹，我們可以為任意代數類型的值（的部分）提供「一般化的 Merkle 證明」，旨在證明具有已知 Merkle 雜湊的樹的某個子樹具有特定值或具有特定雜湊的值。這概括了 \ptref{sp:merkle.proof} 的方法，其中只考慮了 $x[i]=y$ 的 Merkle 證明。

\nxsubpoint\label{sp:tvm.data.shard} \embt(Support for sharding in TON VM data structures.)
我們剛剛概述了如何在不過於複雜的情況下，TON VM 支持高級智能合約語言中的任意（依賴）代數數據類型。然而，對於大型（或全域）智能合約的分片需要在 TON VM 級別上的特殊支援。為此，系統中增加了 hashmap 類型的特殊版本，相當於一個「映射」 $\Account\dashrightarrow X$。這個「映射」可能看起來等同於 $\Hashmap(m,X)$，其中 $\Account=\st2^m$。但是，當一個分片被分成兩個，或兩個分片被合併時，這樣的 hashmaps 會自動被分成兩個，或合併回來，以保留只屬於相應分片的鍵。

\nxsubpoint \embt(Payment for persistent storage.)
TON 區塊鏈的一個值得注意的特點是從智能合約中扣除用於儲存其持久數據的支付（即，增加區塊鏈的總狀態）。它的工作原理如下：

每個區塊都宣布兩種費率，以區塊鏈的主要貨幣（通常是 Toncoin）來提名：保持一個cells在持久儲存中的價格，以及在持久儲存的某個cells中保持一個原始字節的價格。每個賬戶使用的cells和字節的總數據作為其狀態的一部分儲存，所以通過將這些數字乘以在區塊頭中宣布的兩個費率，我們可以計算從賬戶餘額中扣除的支付，以保持其數據在前一個區塊和當前區塊之間。

然而，對於每個賬戶和每個智能合約在每個區塊中的持久儲存使用的支付並不是每次都收取的；而是在賬戶數據中儲存上次收取此支付的區塊的序列號，並且當對賬戶進行任何操作時（例如，轉移價值或接收並由智能合約處理一條消息），在執行任何進一步的操作之前，從賬戶餘額中扣除自上次這樣的支付以來的所有區塊的儲存使用支付。如果賬戶的餘額在此之後變為負數，則該賬戶將被銷毀。

一個工作鏈可能宣稱每個賬戶的一些原始數據字節是「免費的」（即，不參與持久儲存支付），以使「簡單」的賬戶，只在一兩種加密貨幣中保持它們的餘額，免於這些常數支付。

請注意，如果沒有人給一個賬戶發送任何消息，它的持久儲存支付不會被收集，並且它可以無限期地存在。然而，任何人都可以發送，例如，一條空消息來銷毀這樣的賬戶。可以給發送這樣一條消息的人提供一個小的激勵，從要被銷毀的賬戶的原始餘額中收取部分資金。然而，我們預期，validator會免費銷毀這樣的無資金賬戶，僅僅是為了減少全域區塊鏈的狀態大小，並避免保持大量的數據而不得到賠償。

為持久數據的保持收集的支付在 shardchain 或 masterchain 的validator之間分配（在後一種情況下按比例分配他們的股份）。

\nxsubpoint\label{sp:loc.glob.smct} \embt(Local and global smart contracts; smart-contract instances.)
一個智能合約通常只存在於一個分片中，根據智能合約的 $\accountid$ 選擇，與「普通」賬戶類似。這通常對大多數應用程序來說都是足夠的。然而，一些「高負載」的智能合約可能希望在某個工作鏈的每個分片鏈中都有一個「實例」。為了實現這一點，它們必須將它們的創建交易傳播到所有的分片鏈中，例如，通過將此交易提交到工作鏈 $w$ 的「根」分片鏈 $(w,\emptyset)$ 中，並支付一大筆佣金。\footnote{一個更昂貴的選擇是在主鏈中發布這樣一個「全域」智能合約。}

這個動作實際上在每個分片中創建了智能合約的實例，具有單獨的餘額。原始地，創建交易中傳輸的餘額只是通過給分片 $(w,s)$ 的實例 $2^{-|s|}$ 的總餘額的部分來分配。當一個分片分裂成兩個子分片時，所有全域智能合約的實例的餘額都分裂為一半；當兩個分片合併時，餘額加在一起。

在某些情況下，分裂/合併全域智能合約的實例可能涉及這些智能合約的特殊方法的（延遲）執行。默認情況下，餘額按照上述方式分裂和合併，一些特殊的「賬戶索引」的 hashmaps 也是自動分裂和合併的（參見~\ptref{sp:tvm.data.shard}）。

\nxsubpoint \embt(Limiting splitting of smart contracts.)
一個全域智能合約可以在其創建時限制其分裂深度 $d$，以使持久儲存費用更具可預測性。這意味著，如果分片鏈 $(w,s)$ 滿足 $|s|\geq d$ 被分裂成兩個，只有兩個新分片鏈中的一個繼承智能合約的實例。這個分片鏈是確定性選擇的：每個全域智能合約都有一個「$\accountid$」，本質上是其創建交易的雜湊，並且其實例具有與前 $\leq d$ 位替換為適當值的相同的 $\accountid$，以落入正確的分片。這個 $\accountid$ 選擇了分裂後哪個分片將繼承智能合約實例。

\nxsubpoint\label{sp:account.state} \embt(Account/Smart-contract state.)
我們可以總結以上所有內容，得出賬戶或智能合約的狀態包括以下內容：
\begin{itemize}
\item 區塊鏈的主要貨幣的餘額
\item 區塊鏈其他貨幣的餘額
\item 智能合約的程式碼（或其雜湊）
\item 智能合約的持久性數據（或其 Merkle 雜湊）
\item 持久性儲存cells和原始字節使用數量的統計
\item 上次收取智能合約持久性儲存付款的時間（實際上，是主鏈區塊號）
\item 轉移貨幣和從此賬戶發送消息所需的公鑰（可選；默認等於 $\accountid$ 本身）。在某些情況下，更為複雜的簽名檢查程式碼可能位於此處，與比特幣交易輸出類似；然後，$\accountid$ 將等於此程式碼的雜湊。
\end{itemize}
我們還需要在某處保存以下數據，無論是在賬戶狀態中還是在某個其他的賬戶索引的雜湊圖中：
\begin{itemize}
\item 賬戶的輸出消息隊列（參見~\ptref{sp:out.queue}）
\item 最近傳送消息的（雜湊的）集合（參見~\ptref{sp:deliver.q}）
\end{itemize}

並不是每個賬戶都真正需要所有這些；例如，只有智能合約需要智能合約程式碼，而「簡單」的賬戶則不需要。此外，儘管任何賬戶必須在主要貨幣中有一個非零餘額（例如，基礎工作鏈的主鏈和分片鏈的Toncoin），但在其他貨幣中可能有零餘額。為了避免保留未使用的數據，定義了一個乘積型別（取決於工作鏈）（在工作鏈的創建期間），它使用不同的標籤字節（例如，TL 構造器；參見~\ptref{sp:TL}）來區分使用的不同「構造器」。最終，賬戶狀態本身作為TVM持久性儲存的cells集合保存。

\mysubsection{分片鏈間的消息}

TON 區塊鏈的一個重要組件是{\em 區塊鏈間的消息系統\/}。這些區塊鏈可以是同一工作鏈的分片鏈，或者是不同工作鏈的分片鏈。

\nxsubpoint \embt(Messages, accounts and transactions: a bird's eye view of the system.)  
{\em 消息\/}從一個賬戶發送到另一個賬戶。每一個{\em 交易\/}包括一個賬戶接收一個消息，根據某些規則改變其狀態，並生成到其他賬戶的多個（可能是一個或零個）新消息。每條消息生成並接收（傳遞）確切一次。

這意味著消息在系統中扮演了基本的角色，與賬戶（智能合約）的角色相當。從無窮分片範式的角度看（參見~\ptref{sp:ISP}），每個賬戶都位於其獨立的「賬戶鏈」中，並且它唯一可以影響某其他賬戶的狀態的方式是通過發送消息。


\nxsubpoint\label{sp:actors} \embt(Accounts as processes or actors; Actor model.)  
可以將賬戶（和智能合約）視為「進程」或「角色」，它們能夠處理進入的消息、改變其內部狀態，並因此生成一些出站消息。這與所謂的{\em Actor model}密切相關，該模型在Erlang之類的語言中使用（但是，Erlang中的角色通常稱為「進程」）。由於新的角色（即，智能合約）也允許由現有角色作為處理入站消息的結果來創建，因此與Actor model的對應基本上是完整的。

\nxsubpoint \embt(Message recipient.)  
任何消息都有其{\em 接收者}，由{\em 目標工作鏈識別符 $w$}（默認情況下與原始分片鏈相同）和{\em 接收賬戶 $\accountid$}進行描述。$\accountid$的確切格式（即，位數）取決於$w$；但是，碎片始終由其第一個（最重要的）64位確定。

\nxsubpoint\label{sp:msg.sender} \embt(Message sender.)  
在大多數情況下，消息都有一個{\em 發送者}，再次由$(w',\accountid')$對進行描述。如果存在，它位於消息接收者和消息值之後。有時，發送者不重要，或者他是區塊鏈之外的某人（即，不是智能合約），在這種情況下，此字段不存在。

值得注意的是，Actor model並不要求消息有一個隱式發送者。相反，消息可能包含對應該發送請求回覆的Actor的引用；它通常與發送者相符。但是，在加密貨幣（Byzantine）環境中，在消息中有一個明確的不可偽造的發送者字段是很有用的。

\nxsubpoint \embt(Message value.)  
消息的另一個重要特性是其附加的{\em 值}，它是源工作鏈和目標工作鏈均支持的一種或多種加密貨幣。消息的值在消息接收者之後的開頭處指示；它實際上是一系列的$(\currencyid,\vr{value})$對。

請注意，「簡單」賬戶之間的「簡單」值轉移只是帶有某些值的空（無操作）消息。另一方面，略為複雜的消息主體可能包含一個簡單的文本或二進制評論（例如，關於付款的目的）。

\nxsubpoint\label{sp:ext.msg} \embt(External messages, or ``messages from nowhere''.)  
有些消息是從「無處」來的，也就是它們並非由位於區塊鏈中的賬戶（無論是否是智能合約）生成的。最典型的例子是當用戶希望從她控制的賬戶轉移一些資金到另一個賬戶時。在這種情況下，用戶發送一個「來自無處的消息」到她自己的賬戶，要求它生成一個發送給接收賬戶的消息，帶有指定的值。如果此消息被正確簽名，她的賬戶就會接收到它並生成所需的出站消息。

實際上，人們可能會認為「簡單」賬戶是帶有預定義程式碼的智能合約的特例。這種智能合約只接收一種類型的消息。這種入站消息必須包含作為傳遞（處理）入站消息結果要生成的出站消息列表，以及一個簽名。智能合約檢查簽名，如果它是正確的，則生成所需的消息。

當然，「來自無處的消息」和普通消息之間有所不同，因為「來自無處的消息」不能承載值，所以它們不能為自己的「gas」（即它們的處理）付款。相反，它們在甚至被建議包含在新的shardchain塊中之前，會先嘗試執行一個小的gas限制；如果執行失敗（簽名不正確），則「來自無處的消息」被視為不正確並被丟棄。如果執行在小的gas限制內不失敗，則消息可能被包含在新的shardchain塊中並完全處理，從接收者的賬戶中扣除所消耗的gas（處理能力）的付款。 「來自無處的消息」也可以定義一些交易費，這些費用在gas付款之外從接收者的賬戶中扣除，以重新分配給validator。

在這個意義上，「來自無處的消息」或「外部消息」起到了在其他區塊鏈系統中使用的交易候選人的作用（例如，比特幣和以太坊）。

\nxsubpoint \embt(Log messages, or ``messages to nowhere''.)  
同樣，有時可以生成並路由到特定的shardchain的特殊消息，不是為了交付給其收件人，而是為了記錄，以便任何人接收到有關該碎片的更新時都可以輕鬆觀察。這些記錄的消息可以在用戶的控制台中輸出，或觸發某個離鏈伺服器上的某個腳本的執行。在這種意義上，它們代表了「區塊鏈超級電腦」的外部「輸出」，正如「來自無處的消息」代表了「區塊鏈超級電腦」的外部「輸入」。

\nxsubpoint \embt(Interaction with off-chain services and external blockchains.)  
這些外部輸入和輸出消息可以用於與離鏈服務和其他（外部）區塊鏈互動，如比特幣或以太坊。人們可以在TON區塊鏈中創建與比特幣、以太或在以太坊區塊鏈中定義的任何ERC-20代幣相關聯的代幣或加密貨幣，並使用「來自無處的消息」和「去無處的消息」，由位於某些第三方離鏈伺服器上的腳本生成和處理，以實現TON區塊鏈與這些外部區塊鏈之間的必要互動。

\nxsubpoint \embt(Message body.)  {\em message body\/} 基本上就是一系列的位元組，其含義只由接收的工作鏈和/或智能合約決定。對於使用TON VM的區塊鏈，這可以是通過 \texttt{Send()} 操作自動生成的任何 TVM cell 的序列化。這種序列化是通過遞迴地替換 TON VM cell 中的所有參照來獲得的。最終，會出現一串原始位元組，通常在前面加上一個 4 位元組的「消息類型」或「消息建構器」，用於選擇接收智能合約的正確方法。

另一種選擇是使用 TL-序列化對象（參見 \ptref{sp:TL}）作為消息主體。這對於不同工作鏈之間的通信可能尤其有用，其中一個或兩個不一定使用TON VM。

\nxsubpoint \embt(Gas limit and other workchain/VM-specific parameters.)  有時消息需要攜帶有關 gas 限制、gas 價格、交易費用和相似值的資訊，這些值取決於接收的工作鏈，並且只與接收的工作鏈有關，但不一定與原始工作鏈有關。這些參數包含在消息主體中或之前，有時（取決於工作鏈）有特殊的 4 位元組前綴表示它們的存在（可以由 TL-方案定義；參見 \ptref{sp:TL}）。

\nxsubpoint \embt(Creating messages: smart contracts and transactions.)  新消息的來源有兩個。大多數消息是在智能合約執行期間創建的（通過 TON VM中的 \texttt{Send()} 操作），當某個智能合約被調用以處理一個入站消息時。或者，消息可能來自外部，作為「外部消息」或「來自無處的消息」（參見 \ptref{sp:ext.msg}）。%
\footnote{上述只需要在基本工作鏈及其分片鏈上文字上是真實的；其他工作鏈可能提供其他創建消息的方法。}

\nxsubpoint \embt(Delivering messages.)  當一條消息到達包含其目的賬戶的 shardchain 時，\footnote{作為一個退化情況，這個 shardchain 可能與原始的 shardchain 重合——例如，如果我們正在內部工作的工作鏈尚未被分裂。} 它被「傳遞」到其目的地賬戶。接下來會發生什麼取決於工作鏈；從外部觀點看，重要的是這樣的消息從這個 shardchain 永遠不會被進一步轉發。

對於基礎工作鏈的 shardchains，傳送包括將消息值（扣除任何 gas 付款）添加到接收賬戶的餘額，並可能之後調用接收智能合約的一個依賴於消息的方法，如果接收賬戶是一個智能合約。事實上，一個智能合約只有一個進入點用於處理所有傳入消息，並且它必須通過查看它們的前幾個位元組來區分不同類型的消息（例如，包含 TL 建構器的前四個位元組；參見 \ptref{sp:TL}）。

\nxsubpoint \embt(Delivery of a message is a transaction.)  因為消息的交付更改了賬戶或智能合約的狀態，所以它在接收的 shardchain 中是一個特殊的 {\em 交易\/}，並明確地註冊為這樣。本質上，{\em 所有\/} TON 區塊鏈交易都包括將一個入站消息傳遞給其接收賬戶（智能合約），忽略一些次要技術細節。

\nxsubpoint \embt(Messages between instances of the same smart contract.)  回憶一下，一個智能合約可能是 {\em 本地\/} 的（即，像任何普通賬戶一樣駐留在一個 shardchain 中）或 {\em 全域\/} 的（即，在所有的 shards 中都有實例，或至少在所有深度為 $d$ 的 shards 中；參見 \ptref{sp:loc.glob.smct}）。全域智能合約的實例可能需要交換特殊消息以在彼此之間傳遞信息和價值。在這種情況下，（不可偽造的）發件人 $\accountid$ 變得很重要（參見 \ptref{sp:msg.sender}）。

\nxsubpoint \embt(Messages to any instance of a smart contract; wildcard addresses.)  有時候一條消息（例如，客戶端請求）需要被交付給全域智能合約的任何實例，通常是最近的一個（如果有一個駐留在與發件人相同的 shardchain 中，它是明顯的候選人）。做到這一點的一種方法是使用「通配符收件人地址」，其中目標 $\accountid$ 的前 $d$ 位可以取任意值。實際上，人們通常會將這 $d$ 位設置為與發件人的 $\accountid$ 中的相同值。

\nxsubpoint \embt(Input queue is absent.)  由區塊鏈接收的所有消息（通常是 shardchain；有時是 masterchain）——或基本上是駐留在某個 shardchain 內的「賬戶鏈」——都立即被交付（即，由接收賬戶處理）。因此，沒有像這樣的「輸入隊列」。相反，如果由於對區塊總大小和 gas 使用的限制，不是所有目的為特定 shardchain 的消息都可以被處理，一些消息簡單地留在原始 shardchains 的輸出隊列中積累。

\nxsubpoint\label{sp:out.queue} \embt(Output queues.)  從無限分割範例（Infinite Sharding Paradigm）的角度看 (cf.~\ptref{sp:ISP})，每個賬戶鏈（即，每個賬戶）都有其自己的輸出隊列，由它生成但尚未傳遞給其接收者的所有消息組成。當然，賬戶鏈只有一個虛擬的存在；它們被分組到shardchains中，而一個shardchain有一個輸出「隊列」，由屬於該shardchain的所有賬戶的輸出隊列的聯合組成。

這個shardchain輸出「隊列」只對其成員消息施加部分順序。即，在先前的區塊中生成的消息必須在隨後的區塊中生成的任何消息之前被傳遞，並且由相同賬戶生成且具有相同目的地的任何消息必須按照它們的生成順序傳遞。

\nxsubpoint\label{sp:intershard.msgs} \embt(Reliable and fast inter-chain messaging.)  對於像TON這樣的可擴展多區塊鏈專案，能夠在不同的shardchains之間轉發和傳遞消息是至關重要的 (cf.~\ptref{sp:msg.IHR})，即使系統中有數百萬個。消息應該被{\em 可靠地\/}（即，消息不應該丟失或傳遞多次）和{\em 快速地}傳遞。TON區塊鏈通過使用兩種「消息路由」機制的組合來實現這一目標。

\nxsubpoint\label{sp:hypercube} \embt(Hypercube routing: ``slow path''
for messages with assured delivery.)  TON Blockchain 使用「超立方體路由」作為一種緩慢，但安全可靠的方法，從一個 shardchain 傳遞消息到另一個 shardchain，如有必要，使用幾個中間的 shardchain 進行轉發。否則，任何給定的 shardchain 的validator都需要追踪所有其他 shardchain 的狀態（輸出隊列），隨著 shardchain 總數的增加，這將需要過多的計算能力和網路帶寬，從而限制了系統的可擴展性。因此，無法直接從任何 shard 傳遞消息到其他每一個 shard。相反，每個 shard 只與其 $(w,s)$ shard 標識符中確切一個十六進制數位不同的 shard「連接」(cf.~\ptref{sp:shard.ident})。這樣，所有的 shardchain 構成一個「超立方體」圖，消息沿著這個超立方體的邊緣移動。

如果消息被發送到與當前的 shard 不同的 shard，當前的 shard 標識符的十六進制數字（確定地選擇）被替換為目標 shard 的相應數字，並使用所得的標識符作為轉發消息的近端目標。\footnote{這不一定是用於計算超立方體路由的下一跳的算法的最終版本。特別是，十六進制數字可能會被 $r$-位群組替換，其中 $r$ 是一個可配置的參數，不一定等於四。}

超立方體路由的主要優點是區塊有效性條件意味著創建 shardchain 的區塊的validator必須收集和處理「鄰近」shardchain 的輸出隊列中的消息，否則將失去他們的 stake 。這樣，任何消息都可以預期最終會達到其最終目的地；消息不能在過程中丟失或傳遞兩次。

請注意，超立方體路由帶來了一些額外的延遲和開銷，因為必須通過幾個中間的 shardchain 轉發消息。然而，這些中間的 shardchain 的數量增長非常緩慢，作為 shardchain 總數 $N$ 的對數 $\log N$（更確切地說，$\lceil\log_{16}N\rceil-1$）。例如，如果 $N\approx250$，最多只有一個中間的 hop；對於 $N\approx4000$ 的 shardchain，最多有兩個。四個中間的 hop，我們可以支持多達一百萬的 shardchain。我們認為為系統的基本無限的可擴展性支付的這個代價是非常小的。事實上，甚至不必支付這個價格：

\nxsubpoint\label{sp:instant.hypercube} \embt(Instant Hypercube
Routing: ``fast path'' for messages.) TON Blockchain 的一個新功能是它引入了一個「快速路徑」，從一個 shardchain 轉發消息到任何其他 shardchain，在大多數情況下都可以完全繞過 \ptref{sp:hypercube} 中的「慢速」超立方體路由，並在最終目的地 shardchain 的下一個區塊中傳遞消息。

該思路如下。在「慢速」的超立方體路由中，消息在超立方體的邊緣上（在網路中）旅行，但在每個中間頂點都會被延遲（大約五秒鐘），以將其提交到相應的 shardchain，然後再繼續其旅程。

為了避免不必要的延遲，可以沿著超立方體的邊緣轉發消息和一個適當的 Merkle 證明，而不用等待將其提交到中間的 shardchains。實際上，網路消息應該從原始 shard 的「任務組」的validator（cf.~\ptref{sp:val.task.grp}）轉發到目的地 shard 的「任務組」的指定區塊生產者（cf.~\ptref{sp:rot.gen.prio}）；這可能可以直接完成，而不沿著超立方體的邊緣。當這條帶有 Merkle 證明的消息到達目的地 shardchain 的validator（更確切地說，是 collators；cf.~\ptref{sp:collators}）時，他們可以立即將其提交到一個新的區塊，而不用等待消息完成沿著「慢路徑」的旅程。然後將交付確認以及一個適當的 Merkle 證明沿著超立方體的邊緣發回，並且可以通過提交一個特殊的交易來停止消息沿著「慢路徑」的旅程。

請注意，這種「即時交付」機制並未取代在~\ptref{sp:hypercube} 中描述的「慢速」但是不會失敗的機制。仍然需要「慢路徑」，因為validator不能因失去或簡單地決定不將「快速路徑」消息提交到他們區塊鏈的新區塊而受到懲罰。\footnote{然而，validator有一定的動機盡快這樣做，因為他們將能夠收集與消息相關的所有轉發費用，這些費用尚未在慢路徑中被消耗。}

因此，兩種消息轉發方法是平行運行的，只有在「快速」機制的成功證明被提交到一個中間的 shardchain 時，「慢速」機制才會被中止。%\footnote{實際上，可以暫時或永久禁用「即時交付」機制，系統將繼續運行，但速度會慢一些。}

\nxsubpoint\label{sp:collect.input.msg} \embt(Collecting input
messages from output queues of neighboring shardchains.) 當為 shardchain 提議一個新的區塊時，鄰近（在\ptref{sp:hypercube}的路由超立方體意義上）的 shardchains 的一些輸出消息被包含在新的區塊中作為「輸入」消息，並立即被傳遞（即，處理）。關於這些鄰居的輸出消息必須以哪種順序進行處理，有一定的規則。基本上，一個「較舊」的消息（來自參照較舊的主鏈區塊的 shardchain 區塊）必須在任何「較新」的消息之前傳遞；對於來自同一鄰近 shardchain 的消息，必須遵守\ptref{sp:out.queue}中描述的輸出隊列的部分順序。

\nxsubpoint\label{sp:out.q.del} \embt(Deleting messages from output queues.)  一旦觀察到輸出隊列中的訊息已被相鄰的分片鏈交付，則通過特殊交易明確地從輸出隊列中刪除它。

\nxsubpoint\label{sp:deliver.q} \embt(Preventing double delivery of messages.) 為了防止從相鄰的分片鏈的輸出隊列中雙重交付訊息，每個分片鏈（更確切地說，其中的每個賬戶鏈）作為其狀態的一部分保持最近交付的訊息的集合（或僅其雜湊值）。當觀察到已交付的訊息從其源相鄰分片鏈（參見\ptref{sp:out.q.del}）的輸出隊列中被刪除時，它也從最近交付的訊息的集合中被刪除。

\nxsubpoint \embt(Forwarding messages intended for other shardchains.) 通過 Hypercube 路由（參見\ptref{sp:hypercube}）有時出站訊息不是交付給包含預期收件人的分片鏈，而是交付給位於到目的地的超立方體路徑上的相鄰分片鏈。在這種情況下，"交付"包括將入站訊息移動到出站隊列。這在塊中明確地反映為一個特殊的{\em 轉發交易}，其中包含該訊息。本質上，這看起來就像該訊息已被分片鏈內的某人接收，並且生成了一個相同的訊息作為結果。

\nxsubpoint \embt(Payment for forwarding and keeping a message.) 轉發交易實際上消耗了一些瓦斯（取決於被轉發的訊息的大小），因此從被轉發的訊息的值中扣除了一筆瓦斯支付，代表此分片鏈的validator。此轉發支付通常遠小於當訊息最終交付給其收件人時所確定的瓦斯支付，即使該訊息由於超立方體路由而被轉發了多次。此外，只要某個分片鏈的輸出隊列中保持有訊息，它就是分片鏈的全域狀態的一部分，因此特殊交易也可能收取長時間保持全域數據的支付。

\nxsubpoint \embt(Messages to and from the masterchain.) 訊息可以直接從任何分片鏈發送到主鏈，反之亦然。但是，發送訊息到主鏈以及在主鏈中處理訊息的瓦斯價格相當高，因此只有在真正需要時才會使用此功能——例如，由validator來存入他們的 stake 。在某些情況下，可能會定義發送到主鏈的訊息的最小存款（附加值），只有當接收方認為該訊息是“有效”的時候才會退還。

訊息不能自動通過主鏈路由。帶有 $\workchainid\neq-1$ 的訊息（其中 $-1$ 是表示主鏈的特殊 $\workchainid$）不能交付給主鏈。

原則上，人們可以在主鏈內部創建一個訊息轉發智能合約，但使用它的價格將是禁止性的。

\nxsubpoint \embt(Messages between accounts in the same shardchain.)
在某些情況下，某個分片鏈中的賬戶生成的訊息，目標是同一分片鏈中的另一賬戶。例如，這發生在新的工作鏈中，因為負載是可管理的，所以尚未分裂成多個分片鏈。

這樣的訊息可能會在分片鏈的輸出隊列中累積，然後在後續的區塊中作為入站訊息進行處理（為此目的，任何分片都被視為其本身的鄰居）。然而，在大多數情況下，有可能在起源區塊本身內交付這些訊息。

為了實現這一點，對包含在分片鏈區塊中的所有交易施加了部分排序，並尊重此部分順序處理交易（每個交易都包含將訊息交付給某個賬戶）。特別是，允許一個交易處理與此部分順序相對的前一個交易的某個輸出訊息。

在這種情況下，訊息主體不會被複製兩次。相反，起源交易和處理交易都參照訊息的共享副本。

\mysubsection{全域 Shardchain 狀態。"Bag of Cells"哲學。}


現在我們準備描述TON區塊鏈的全域狀態，或者至少是基本工作鏈的分片鏈。

我們從“高級”或“邏輯”描述開始，即全域狀態是代數類型 $\tp{ShardchainState}$ 的值。

\nxsubpoint\label{sp:shard.state} \embt(Shardchain state as a
collection of account-chain states.)  根據無限分片模型（參見\ptref{sp:ISP}），任何分片鏈只是虛擬“賬戶鏈”的（臨時）集合，每個賬戶鏈只包含一個賬戶。這意味著，本質上，全域分片鏈狀態必須是一個雜湊映射
\begin{equation}\label{eq:simple.shard.st}
  \tp{ShardchainState}:=(\Account\dashrightarrow\tp{AccountState})
\end{equation}
其中所有作為此雜湊映射的指數出現的 $\accountid$ 必須以前綴 $s$ 開始，如果我們正在討論分片 $(w,s)$ 的狀態（參見\ptref{sp:shard.ident}）。

實際上，我們可能希望將 $\tp{AccountState}$ 分成幾個部分（例如，保持賬戶輸出訊息隊列的獨立，以簡化相鄰分片鏈的檢查），並在 $\tp{ShardchainState}$ 內部擁有幾個雜湊映射 $(\Account\dashrightarrow\tp{AccountStatePart}_i)$。我們還可能向 $\tp{ShardchainState}$ 添加少量“全域”或“整體”參數，（例如，屬於此分片的所有賬戶的總餘額，或所有輸出隊列中的訊息總數）。

然而，\eqref{eq:simple.shard.st} 是分片鏈全域狀態的一個很好的初步近似值，至少從“邏輯”（“高級”）的角度來看。可以使用TL方案（參見\ptref{sp:TL}）的幫助來進行代數類型 $\tp{AccountState}$ 和 $\tp{ShardchainState}$ 的正式描述，該描述將在其他地方提供。

\nxsubpoint\label{sp:split.merge.state} \embt(Splitting and merging shardchain states.)
請注意，無限分片模型描述的分片鏈狀態 \eqref{eq:simple.shard.st} 顯示了當分片被分裂或合併時，該狀態應如何被處理。實際上，這些狀態變換變得是非常簡單的雜湊映射操作。

\nxsubpoint \embt(Account-chain state.)
(虛擬的)賬戶鏈狀態只是一個賬戶的狀態，由類型 $\tp{AccountState}$ 描述。通常它具有在~\ptref{sp:account.state} 中列出的所有或某些字段，具體取決於使用的構造器。

\nxsubpoint \embt(Global workchain state.)
與 \eqref{eq:simple.shard.st} 類似，我們可以使用相同的公式定義全域的 {\em workchain\/} 狀態，但 $\accountid$'s 可以取任何值，不僅僅是屬於一個分片的值。在這種情況下，也適用於~\ptref{sp:shard.state} 中所做的類似備註：我們可能想要將此雜湊映射分裂成幾個雜湊映射，我們可能想要添加一些“整體”的參數，如總餘額。

本質上，全域的工作鏈狀態 {\em must\/} 被給予與分片鏈狀態相同的類型 $\tp{ShardchainState}$，因為如果這個工作鏈的所有現有分片鏈突然合併成一個，我們會得到的就是這個分片鏈狀態。

\nxsubpoint\label{sp:bag.of.cells} \embt(Low-level perspective: ``bag of cells''.)  
存在一個「低階」描述關於賬戶鏈或shardchain狀態，這與上述的「高階」描述是互補的。此描述相當重要，因為它事實上是非常普遍的，為代表、儲存、序列化和通過網路轉移TON Blockchain（包括blocks、shardchain states、smart-contract storage、Merkle proofs等）所用的幾乎所有資料提供了一個共同的基礎。同時，一旦這樣的普遍「低階」描述被理解和實施，我們就可以集中注意力僅考慮「高階」。

回想一下，TVM用一棵「TVM cells」樹，或簡稱為「cells」（參見~\ptref{sp:tvm.cells}和~\ptref{sp:TL}）來表示任意代數類型的值（例如，~\eqref{eq:simple.shard.st}中的$\tp{ShardchainState}$）。

每個這樣的cell都由兩個「descriptor bytes」組成，定義某些標誌和值$0\leq b\leq 128$，表示原始bytes的數量，以及$0\leq c\leq 4$，這是指向其他cells的引用數量。然後是$b$個原始bytes和$c$個cell引用。\footnote{可以顯示，如果經常需要儲存在cell樹中的所有資料的Merkle proofs，則應該使用$b+ch\approx 2(h+r)$的cells來最小化平均Merkle proof大小，其中$h=32$是hash在bytes中的大小，而$r\approx4$是cell引用的「byte大小」。換句話說，一個cell應該包含兩個引用和一些原始bytes，或一個引用和大約36原始bytes，或完全沒有引用但是有72原始bytes。}

cell引用的確切格式取決於它的實現，以及cell是否位於RAM、磁碟、網路封包、block等。一個有用的抽象模型是想像所有cells都存放在內容可寄存的記憶體中，cell的地址等於其($\Sha$) hash。回想一下，cell的(Merkle) hash正是通過將其子cell的引用替換為它們（遞迴計算的）hashes並hash生成的byte string來計算的。

這樣，如果我們使用cell hashes來引用cells（例如，在其他cells的描述中），系統稍微簡化，且cell的hash開始與代表它的byte string的hash相符。

現在我們看到，{\em 任何TVM可以表示的對象，包括全域shardchain狀態，都可以表示為一個「bag of cells」} ——即，{\em 一個cells的集合以及指向其中之一的「root」引用}（例如，通過hash）。請注意，重複的cells從此描述中被刪除了（「bag of cells」是cells的集合，而不是多重集），所以抽象的樹表示實際上可能變成了一個有向無環圖(dag)表示。


人甚至可以在硬碟上使用$B$-tree或$B+$-tree來保存這個狀態，包含所有相關的cells（也許還有一些附加數據，如子樹高度或引用計數器），並由cell hash進行索引。但是，這個想法的簡單實現會導致一個智能合約的狀態被散佈在硬碟文件的遠處，這是我們想要避免的。\footnote{更好的實現方法是，如果smart contract的狀態很小，就將其保存為序列化的字符串，如果很大，則保存在另一個$B$-tree中；然後代表blockchain狀態的頂層結構將是一個$B$-tree，其葉子節點被允許包含對其他$B$-tree的引用。}

現在我們將詳細解釋TON Blockchain使用的幾乎所有對象如何可以表示為「bag of cells」，從而展示這種方法的普遍性。

\nxsubpoint \embt(Shardchain block as a ``bag of cells''.)  
Shardchain block本身也可以用代數類型來描述，並儲存為「bag of cells」。然後可以通過簡單地連接表示「bag of cells」中每個cell的byte strings（以任意順序）來獲得block的簡單二進制表示。這種表示可以進一步改進和優化，例如，在block的開頭提供所有cells的偏移量列表，並在可能的情況下用32位索引替換對其他cells的hash引用。然而，人們應該認識到block本質上是一個「bag of cells」，所有其他技術細節只是次要的優化和實現問題。

\nxsubpoint\label{sp:obj.update} \embt(Update to an object as a ``bag of cells''.)  
想像我們有一個以「bag of cells」表示的對象的舊版本，我們想要表示同一對象的新版本，這個新版本應該與前一個不太不同。一個方法是簡單地將新狀態表示為具有自己root的另一個「bag of cells」，{\em 並從中刪除所有在舊版本中出現的cells}。剩下的「bag of cells」基本上是對象的{\em update\/}。每個擁有此對象的舊版本和update的人都可以計算新版本，只需合併兩個bag of cells，並刪除舊的root（減少其引用計數，並在引用計數變為零時釋放cell）。

\nxsubpoint \embt(Updates to the state of an account.)
特別是，對賬戶的狀態、shardchain的全域狀態或任何hashmap的更新都可以使用在~\ptref{sp:obj.update}中描述的想法進行表示。這意味著當我們接收到一個新的shardchain block（即是「bag of cells」）時，我們不只是單獨解釋這個「bag of cells」，而是首先將其與代表shardchain先前狀態的「bag of cells」結合。從這個意義上說，每個block可能都「包含」blockchain的整體狀態。

\nxsubpoint \embt(Updates to a block.)
回憶一下，block本身就是一個「bag of cells」，所以，如果需要編輯block，則可以類似地將「block update」定義為「bag of cells」，並在存在該block的先前版本的「bag of cells」的情境下進行解釋。這大致上是在~\ptref{sp:inv.sh.blk.corr}中討論的「垂直blocks」背後的想法。

\nxsubpoint\label{sp:merkle.as.BoC} \embt(Merkle proof as a ``bag of cells''.)
注意，一個（廣義的）Merkle證明——例如，從已知的$\Hash(x)=h$開始聲稱$x[i]=y$（參見~\ptref{sp:merkle.proof}和~\ptref{sp:gen.merkle.proof}）——也可以表示為「bag of cells」。具體來說，只需要提供一組cells子集，對應從$x:\Hashmap(n,X)$的根到其所需的具有索引$i:\st2^n$和值$y:X$的葉子的路徑。在此證明中，不位於此路徑上的這些cells的子項的引用將保持「未解決」，由cell hashes表示。還可以同時提供，例如，$x[i]=y$和$x[i']=y'$的Merkle證明，通過在「bag of cells」中包括位於從$x$的根到對應於索引$i$和~$i'$的葉子的兩條路徑的聯合上的cells。

\nxsubpoint\label{sp:merkle.query.resp} \embt(Merkle proofs as query responses from full nodes.)
實質上，擁有shardchain（或account-chain）狀態完整副本的完整節點可以在被輕節點（例如，運行TON Blockchain客戶端輕版本的網路節點）請求時提供Merkle證明，使接收者能夠僅使用此Merkle證明中提供的cells執行一些簡單的查詢，而不需要外部幫助。輕節點可以將其查詢以序列化格式發送給完整節點，並接收正確的答案和Merkle證明——或僅僅是Merkle證明，因為請求者應該能夠僅使用Merkle證明中包含的cells來計算答案。這個Merkle證明將僅由一個「bag of cells」組成，只包含屬於shardchain狀態的那些cells，在執行輕節點的查詢時由完整節點訪問。此方法尤其可用於執行智能合約的「get queries」（參見~\ptref{sp:tent.exec.get}）。

\nxsubpoint\label{sp:aug.upd} \embt(Augmented update, or state update with Merkle proof of validity.)
回想一下（參見~\ptref{sp:obj.update}），我們可以透過「update」來描述從舊值$x:X$到新值$x':X$的物件狀態變化，這只是一個「bag of cells」，其中包含那些位於表示新值$x'$的子樹中的cells，但不包含位於表示舊值$x$的子樹中的cells，因為假設接收者擁有舊值$x$及其所有的cells複本。

然而，如果接收者並沒有$x$的完整複本，而只知道其（Merkle）hash $h=\Hash(x)$，它將無法檢查update的有效性（即update中的所有「懸空」cell引用確實指向存在於$x$的樹中的cells）。我們希望能夠具有可驗證性的update，並加上對舊狀態中所有引用cells存在的Merkle證明。這樣，只知道$h=\Hash(x)$的任何人都能夠檢查update的有效性，並自行計算新的$h'=\Hash(x')$。

因為我們的Merkle證明本身就是「bags of cells」（參見~\ptref{sp:merkle.as.BoC}），可以將這樣的「增強update」構造為一個「bag of cells」，其中包含$x$的舊根、其某些子孫以及從$x$的根到它們的路徑，以及$x'$的新根和其所有不屬於$x$的子孫。

\nxsubpoint \embt(Account state updates in a shardchain block.)
特別是，在shardchain block中的賬戶狀態更新應按照~\ptref{sp:aug.upd}中討論的方式進行增強。否則，某人可能提交一個包含在舊狀態中不存在的cell引用的無效狀態更新的block；證明此block的無效性將是困難的（挑戰者如何證明cell {\em 不是\/}先前狀態的一部分？）。

現在，如果包含在block中的所有狀態更新都是增強的，它們的有效性可以輕鬆檢查，並且其無效性也可以輕鬆顯示為違反（廣義）Merkle hashes的遞迴定義特性。

\nxsubpoint\label{sp:everything.is.BoC} \embt(``Everything is a bag of cells'' philosophy.)
前面的討論表明，我們在TON Blockchain或網路中需要儲存或傳輸的所有內容都可以表示為「bag of cells」。這是TON Blockchain設計哲學的重要部分。一旦解釋了「bag of cells」方法並定義了一些「bags of cells」的「低階」序列化，就可以在抽象（依賴性）代數數據類型的高層次上定義所有內容（如block格式、shardchain和賬戶狀態等）。

「一切都是bag of cells」哲學的統一效果大大簡化了看似不相關的服務的實現；有關涉及付款通道的示例，請參見~\ptref{sp:ton.smart.pc.supp}。

\nxsubpoint \embt(Block ``headers'' for TON blockchains.)  通常，blockchain中的block會從一個小型的header開始，其中包含前一個block的hash、創建時間、block中所有交易的樹的Merkle hash等。然後，block的hash被定義為這個小型block header的hash。因為block header最終取決於block中包含的所有數據，所以無法在不改變其hash的情況下修改block。

在TON blockchains的block使用的``bag of cells''方法中，沒有指定的block header。相反，block hash被定義為block的根cell的(Merkle) hash。因此，block的頂部（根）cell可能被視為此block的小型``header''。

但是，根cell可能不包含通常期望從這樣的header中獲得的所有數據。本質上，人們希望header包含$\Block$數據類型中定義的某些字段。通常，這些字段將包含在幾個cell中，包括根cell。這些cell一起構成了有關字段值的``Merkle proof''。人們可能會堅持在block中的任何其他cell之前，在一開始就包含這些``header cells''。然後，只需要下載block序列化的前幾個字節，就可以獲得所有的``header cells''，並了解所有期望的字段。

\mysubsection{創建和驗證新的Blocks}\label{sect:validators}

TON Blockchain最終由shardchain和masterchain blocks組成。為了系統順利且正確地運作，必須創建、驗證這些blocks，並通過網路將其傳播到所有相關方。


\nxsubpoint\label{sp:validators} \embt(validators.)  新的blocks由特定的節點創建和驗證，這些節點被稱為{\em validators}。實質上，任何希望成為validator的節點都可以成為validator，前提是它可以在masterchain中存入足夠多的抵押金（以TON幣，即Toncoin；參考\ Appendix~\ptref{app:coins}）。validators為良好的工作獲得一些「獎勵」，即所有交易、儲存和燃氣費用，以及一些新鑄造的幣，這反映了整個社群對validators的「感激」，因為它們使TON Blockchain持續運作。這筆收入按照所有參與validators的抵押金比例分配。

然而，成為validator是一項重大的責任。如果validator簽署了一個無效的block，它可能會失去部分或全部的抵押金，並且可能會暫時或永久地被排除在validators之外。如果validator不參與創建block，它不會收到與該block相關的獎勵部分。如果validator長時間不創建新的blocks，它可能會失去部分的抵押金，並被暫停或永久排除在validators之外。

這一切都意味著validator不是輕而易舉地獲得金錢。事實上，它必須追踪所有或某些shardchains的狀態（每個validator負責驗證和創建某一子集shardchains中的新blocks），執行這些shardchains中的智能合約所請求的所有計算，接收其他shardchains的更新等等。這項活動需要大量的磁碟空間、計算能力和網路帶寬。

\nxsubpoint \embt(validators instead of miners.)  請記住，TON Blockchain使用的是Proof-of-Stake方法，而不是Bitcoin、當前版本的Ethereum和大多數其他加密貨幣採用的Proof-of-Work方法。這意味著人們不能通過提供某些工作證明（計算大量其他無用的hashes）來「挖掘」新的block，並因此獲得一些新的幣。相反，人們必須成為validator，並花費自己的計算資源來儲存和處理TON Blockchain的請求和數據。簡而言之，{\em 要挖新幣，必須成為validator。}就這一點而言，{\em validators就是新的miners。}

但是，除了成為validator之外，還有一些其他方式可以賺取幣。

\nxsubpoint\label{sp:nominators} \embt(Nominators and ``mining pools''.)  要成為validator，通常需要購買和安裝幾臺高性能的伺服器，並為它們提供良好的互聯網連接。這不像當前挖掘比特幣所需的ASIC設備那麼昂貴。但你絕對不能在家用電腦上挖新的TON幣，更不用說智能手機了。

在比特幣、以太坊和其他Proof-of-Work加密貨幣挖掘社區中，有一個名為{\em mining pools}的概念，其中許多節點因計算能力不足而無法自行挖掘新的blocks，所以他們合併力量並在之後分享獎勵。

Proof-of-Stake世界中的相應概念是{\em nominator}。實質上，這是一個將其資金借給validator以增加其抵押金的節點；然後validator將其獎勵的相應部分（或之前同意的一部分，例如50\%）分配給nominator。

通過這種方式，nominator也可以參與「挖掘」並獲得與其存款金額成正比的一些獎勵。它只獲得validator獎勵的一部分，因為它只提供了「資本」，但不需要購買計算能力、儲存和網路帶寬。

但是，如果validator因無效行為而失去其抵押金，nominator也會失去其抵押金的部分。在這種意義上，nominator {\em 分擔風險}。它必須明智地選擇其nominated validator，否則可能會損失資金。在這種意義上，nominator進行加權決策並使用其資金「投票」支持某些validator。

另一方面，這種提名或借貸系統使人們能夠成為validator，而無需首先投入大量金錢購買Toncoin（TON幣）。換句話說，它防止持有大量Toncoin的人壟斷validator的供應。

\nxsubpoint\label{sp:fish} \embt(Fishermen: obtaining money by pointing out others' mistakes.)  另一種不成為validator而獲得一些獎勵的方式是成為一名{\em fisherman}。實質上，任何節點都可以通過在masterchain中存入少量資金成為fisherman。然後，它可以使用特殊的masterchain交易來發布某些由validators之前簽名和發布的（通常是shardchain）blocks的（Merkle）無效性證明。如果其他validators同意這個無效性證明，則違規的validators將被懲罰（失去其抵押金的一部分），fisherman則獲得一些獎勵（從違規的validators中沒收的幣的一部分）。之後，如~\ptref{sp:inv.sh.blk.corr}中所述，必須更正無效的（shardchain）block。更正無效的masterchain blocks可能需要在先前提交的masterchain blocks之上創建「垂直」blocks（參見~\ptref{sp:inv.sh.blk.corr}）；無需創建masterchain的分叉。

通常，一個fisherman需要成為至少某些shardchains的完整節點，並花費一些計算資源來運行至少一些智能合約的程式碼。雖然fisherman不需要像validator那麼多的計算能力，但我們認為，一個天生的fisherman是一個準備處理新blocks，但尚未被選為validator的候選者（例如，由於未能存入足夠大的抵押金）。

\nxsubpoint\label{sp:collators} \embt(Collators: obtaining money by
suggesting new blocks to validators.)  另一種不成為validator但可以獲得一些獎勵的方法是成為一個{\em collator}。這是一個節點，它為validator準備並建議新的shardchain block候選者，並使用從此shardchain的狀態和其他(通常是相鄰的) shardchains中取得的資料進行補充（collated），伴隨適當的Merkle證明。當需要從鄰近的shardchains轉發一些消息時，這是必要的。然後，validator可以輕鬆檢查所提議的block候選者的有效性，無需下載此或其他shardchains的完整狀態。

由於validator需要提交新的(collated) block候選者以獲得一些（``mining''）獎勵，因此有理由支付一部分獎勵給願意提供適當block候選者的collator。這樣，validator可以避免觀察鄰近shardchains的狀態，將其外包給collator。

然而，我們預期在系統的初始部署階段不會有單獨指定的collators，因為所有validators都將能夠為自己充當collators。

\nxsubpoint \embt(Collators or validators: obtaining money for
including user transactions.)  使用者可以向一些collators或validators打開micropayment通道，並支付少量的幣以換取在shardchain中包括他們的交易。

\nxsubpoint\label{sp:global.valid} \embt(Global validator set
election.)  每月一次（實際上是每$2^{19}$個masterchain blocks）選舉``global''的validators集合。此集合在一個月前確定並被全域知悉。

要成為validator，節點必須將一些TON幣（Toncoin）轉入masterchain，然後將它們發送到特定的智能合約作為其建議的抵押金$s$。與抵押金一起發送的另一個參數是$l\geq 1$，這是此節點願意接受的相對於最小可能值的最大驗證負載。還有一個$l$的全域上限（另一個可配置參數）$L$，例如說是10。

然後，這個智能合約選舉global的validator集合，只需選擇最大的建議抵押金的前$T$個候選者並公布其身份。最初，validators的總數是$T=100$；隨著負載的增加，我們預期它將增長到1000。它是一個可配置參數（參見~\ptref{sp:config.param}）。

每個validator的實際抵押金如下計算：如果前$T$個提議的抵押金是$s_1\geq s_2\geq\cdots\geq s_T$，那麼第$i$個validator的實際抵押金設定為$s'_i:=\min(s_i,l_i\cdot s_T)$。這樣，$s'_i/s'_T\leq l_i$，所以第$i$個validator不會獲得超過$l_i\leq L$倍最弱validator的負載（因為負載最終與抵押金成正比）。

然後，當選的validators可以撤回他們未使用的抵押金部分，$s_i-s'_i$。不成功的validator候選人可以撤回他們所有的建議抵押金。

每個validator發布其{\em public signing key}，並不一定等於抵押金來源的帳戶的公鑰。\footnote{對於每次validator選舉，生成和使用新的密鑰對是有意義的。}

validators的抵押金被凍結，直到他們被選舉的時期結束，再加上一個月，以防新的爭議出現（例如，發現一個由這些validators簽名的無效block）。之後，將返回抵押金，以及在此期間鑄造的validator的幣份額和處理的交易的費用。


\nxsubpoint\label{sp:val.task.grp} \embt(Election of validator ``task
groups''.)  整體的全域validator集合（其中每個validator都被視為具有與其股份相等的多重性 - 否則validator可能會被誘使承擔多個身份並在它們之間劃分其股份）只用於驗證新的 masterchain 區塊。 shardchain 的區塊只由特定選擇的validator子集驗證，這些validator是從在\ptref{sp:global.valid}中描述的選擇的全域validator集合中選擇的。

這些validator「子集」或「任務組」，為每個 shard 定義，每小時（實際上，每 $2^{10}$ 個 masterchain 區塊）旋轉一次，它們在一小時前就已知，因此每個validator都知道它將需要驗證哪些 shards，並可以為此做準備（例如，通過下載丟失的 shardchain 數據）。

用於為每個 shard $(w,s)$ 選擇validator任務組的算法是確定性偽隨機的。它使用validator嵌入到每個 masterchain 區塊中的偽隨機數（通過使用閾值簽名生成的共識生成）來創建一個隨機種子，然後例如為每個validator計算 $\Hash(\code(w).\code(s).\vr{validator\_id}.\vr{rand\_seed})$。然後按此 hash 的值對validator進行排序，並選擇第一個validator，以便至少具有總validator股份的 $20/T$ 並且由至少5個validator組成。

這種選擇可以由特殊的智能合約完成。在這種情況下，選擇算法將可以輕鬆升級，無需通過\ptref{sp:config.param}中提到的投票機制進行硬分叉。迄今為止提到的所有其他「常數」（例如 $2^{19}$、$2^{10}$、$T$、20 和 5）也都是可配置的參數。

\nxsubpoint\label{sp:rot.gen.prio} \embt(Rotating priority order on
each task group.)  在 shard 任務組的成員上有一個特定的「優先順序」，取決於先前 masterchain 區塊的 hash 和 (shardchain) 區塊序列號。此順序是通過生成並排序上述的某些 hash 來確定的。

當需要生成新的 shardchain 區塊時，通常選擇用於創建此區塊的 shard 任務組validator是根據此旋轉「優先順序」的第一名。如果它未能創建該區塊，第二或第三個validator也可能這樣做。基本上，他們都可以建議他們的區塊候選者，但是由具有最高優先權的validator建議的候選者應該作為 Byzantine Fault Tolerant (BFT) 共識協議的結果獲勝。


\nxsubpoint\label{sp:sh.blk.cand.prop} \embt(Propagation of shardchain
block candidates.)  因為shardchain任務組的成員資格提前一小時就已知，它們的成員可以利用這段時間建立一個專用的「shard validator多播覆蓋網路」，使用TON Network的一般機制 (cf.~\ptref{sect:overlay})。當需要生成一個新的shardchain區塊時—通常在最近的masterchain區塊被傳播後的一兩秒鐘—每個人都知道誰有最高的優先權生成下一個區塊 (cf.~\ptref{sp:rot.gen.prio})。這個validator將創建一個新的整合的區塊候選者，無論是自己還是在整合者的幫助下 (cf.~\ptref{sp:collators})。validator必須檢查（驗證）此區塊候選者（尤其是如果它是由某個整合者準備的）並用其（validator）私鑰簽名。然後，使用預先安排的多播覆蓋網路將區塊候選者傳播到任務組的其餘部分 (該任務組根據\ptref{sect:overlay}中的解釋創建自己的私有覆蓋網路，然後使用\ptref{sp:streaming.multicast}中描述的串流多播協議的版本來傳播區塊候選者)。

真正的BFT方式是使用拜占庭多播協議，例如Honey Badger BFT中使用的協議~\cite{HoneyBadger}：通過一個$(N,2N/3)$-消除程式碼對區塊候選者進行編碼，將結果數據的$1/N$直接發送到組的每個成員，並期望他們將其數據的部分直接多播到組的所有其他成員。

然而，一個更快且更簡單的方法（參見\ptref{sp:streaming.multicast}）是將區塊候選者分成一系列簽名的一千字節區塊（「chunks」），通過Reed--Solomon或泉程式碼（如RaptorQ code~\cite{RaptorQ} \cite{Raptor}）擴充它們的序列，並開始傳輸chunks到「多播網格」（即覆蓋網路）中的鄰居，期望他們將這些chunks進一步傳播。一旦validator獲得足夠的chunks來從中重建區塊候選者，它就會簽署一個確認收據並通過其鄰居將其傳播到整個組。然後，它的鄰居停止向它發送新的chunks，但可能會繼續發送這些chunks的（原始）簽名，認為該節點可以通過應用Reed--Solomon或泉程式碼自行生成後續的chunks（擁有所有必要的數據），將它們與簽名組合起來，並傳播給還沒有準備好的鄰居。

如果在移除所有「壞」節點後「多播網格」（覆蓋網路）仍保持連接（回想一下，允許最多三分之一的節點以拜占庭方式壞掉，即以任意惡意方式行為），則此算法將以最快的方式傳播區塊候選者。

不僅指定的高優先級區塊創建者可以將其區塊候選者多播到整個組。第二和第三優先順序的validator可能會開始多播他們的區塊候選者，無論是立即還是在未能從最高優先級的validator那裡接收到區塊候選者之後。但是，通常只有最大優先權的區塊候選者將被所有（實際上，至少由三分之二的任務組）validator簽名並作為新的shardchain區塊提交。


\nxsubpoint \embt(Validation of block candidates.)  一旦 block candidate 被 validator 接收並檢查其起始 validator 的簽名，接收 validator 會檢查此 block candidate 的有效性，執行其中的所有交易並確保其結果與所聲稱的一致。從其他區塊鏈導入的所有消息都必須在 collated data 中有適當的 Merkle 證明，否則 block candidate 將被視為無效（並且，如果此證明被提交到 masterchain，則可能會懲罰已經簽署此 block candidate 的 validator）。另一方面，如果 block candidate 被認定為有效，接收 validator 會簽署它並將其簽名傳播給組中的其他 validator，可以通過「mesh multicast network」或直接的網路消息。

我們想強調，{\em validator 在檢查（collated）block candidate 的有效性時，不需要訪問此 shardchain 或相鄰 shardchain 的狀態}。\footnote{一個可能的例外是相鄰 shardchain 的輸出隊列的狀態，因為在這種情況下，Merkle 證明的大小可能會變得過大。} 這使得驗證可以非常快速地進行（不需要硬碟訪問），並減輕了 validator 的計算和儲存負擔（尤其是如果他們願意接受外部 collators 的幫助來創建 block candidate）。

\nxsubpoint\label{sp:new.shardc.blk} \embt(Election of the next block candidate.)  一旦 block candidate 收集到 task group 中至少三分之二（按 stake）的 validator 的有效簽名，它就有資格被提交為下一個 shardchain block。運行一個 BFT 協議來達成對所選 block candidate 的共識（可能有多個提議），所有「好的」validator 都會優先選擇該輪中優先級最高的 block candidate。運行此協議的結果是，該 block 會被至少三分之二的 validator（按 stake）的簽名所增強。這些簽名不僅證明了所問 block 的有效性，還證明了它是由 BFT 協議選出的。之後，將 block（無 collated data）與這些簽名組合，以確定的方式序列化，然後通過網路傳播給所有相關方。

\nxsubpoint \embt(validators must keep the blocks they have signed.)  在他們成為 task group 的成員期間，以及之後至少一小時（或者 $2^{10}$ blocks），validator 預期會保留他們已簽署和提交的 block。如果未能向其他 validator 提供簽署的 block，可能會受到懲罰。

\nxsubpoint \embt(Propagating the headers and signatures of new shardchain blocks to all validators.)  validator 將新生成的 shardchain block 的 headers 和簽名傳播到全域 set of validators，使用類似於為每個 task group 創建的 multicast mesh network。

\nxsubpoint\label{sp:new.master.blk} \embt(Generation of new masterchain blocks.)  在所有（或幾乎所有）新的 shardchain block 生成之後，可以生成一個新的 masterchain block。這個程序基本上與 shardchain block 相同（參見~\ptref{sp:new.shardc.blk}），不同之處在於所有 validator（或至少三分之二的 validator）都必須參與此過程。因為新的 shardchain block 的 headers 和簽名被傳播給所有的 validator，所以每個 shardchain 中最新的 block 的 hash 可以並且必須被包含在新的 masterchain block 中。一旦這些 hash 被提交到 masterchain block，外部觀察者和其他 shardchain 可以認為新的 shardchain block 已經提交並且是不可變的（參見~\ptref{sp:sc.hash.mc}）。


\nxsubpoint \embt(validators must keep the state of masterchain.)  
所有的validator都預期要追踪 masterchain 的狀態，而不依賴於彙整的數據。這很重要，因為validator工作組的知識是從 masterchain 的狀態中衍生出來的。

\nxsubpoint \embt(Shardchain blocks are generated and propagated in parallel.)  
通常，每個validator都是幾個 shardchain 任務組的成員;他們的數量（因此validator的負載）大約與validator的股份成正比。這意味著validator同時運行多個新的 shardchain 區塊生成協議。

\nxsubpoint \embt(Mitigation of block retention attacks.)  
因為所有validator在只看到其標頭和簽名後就將一個新的 shardchain 區塊的 hash 插入到 masterchain 中，因此存在一個小概率，即生成此區塊的validator會密謀並試圖避免發佈整個新區塊。這將導致鄰近 shardchains 的validator無法創建新的區塊，因為一旦它的 hash 被提交到 masterchain 中，他們必須至少知道新區塊的輸出消息隊列。

為了緩解這種情況，新區塊必須從其他一些validator（例如，鄰近 shardchains 的任務組聯合的三分之二）收集簽名，證明這些validator確實擁有此區塊的副本並且願意在需要時將它們發送給其他validator。只有在提供這些簽名之後，新區塊的 hash 才可能包含在 masterchain 中。

\nxsubpoint \embt(Masterchain blocks are generated later than shardchain blocks.)  
Masterchain 區塊大約每五秒生成一次，就像 shardchain 區塊一樣。但是，雖然所有 shardchains 中的新區塊的生成基本上是同時進行的（通常由釋放新的 masterchain 區塊觸發），但新的 masterchain 區塊的生成被故意延遲，以允許在 masterchain 中包含新生成的 shardchain 區塊的 hashes。

\nxsubpoint\label{sp:slow.valid} \embt(Slow validators may receive lower rewards.)  
如果一個validator“慢”，它可能無法驗證新的區塊候選者，並且收集提交新區塊所需的三分之二的簽名可能不需要它的參與。在這種情況下，它將收到與此區塊相關的較低份額的獎勵。

這為validator提供了一個激勵，以優化他們的硬體、軟體和網路連接，以便盡可能快地處理用戶交易。

但是，如果validator在區塊提交之前未簽名，則其簽名可能包含在接下來的一個或多個區塊中，然後這部分獎勵（根據已生成多少區塊而呈指數下降---例如，如果validator延遲$k$區塊則為$0.9^k$）仍將給予此validator。


\nxsubpoint\label{sp:val.sign.depth} \embt(``Depth'' of validator signatures.)  
通常，當validator簽署一個區塊時，該簽名只證明了區塊的{\em 相對有效性\/}：只要這個和其他 shardchains 的所有先前區塊都是有效的，這個區塊就是有效的。validator不能因為將先前區塊中提交的無效數據視為理所當然而受到懲罰。

然而，區塊的validator簽名有一個稱為“深度”的整數參數。如果它是非零的，那就意味著validator也宣稱先前指定數量的區塊的(相對)有效性。這是“慢”或“暫時離線”的validator趕上並簽署一些已經提交但未經他們簽名的區塊的方式。然後區塊獎勵的一部分仍將給予他們（參見~\ptref{sp:slow.valid}）。

\nxsubpoint\label{sp:abs.val.from.rel} \embt(validators are responsible for {\em relative\/} validity of signed shardchain blocks; absolute validity follows.)  
我們想再次強調，validator在 shardchain 區塊 \(B\) 上的簽名只證明了該區塊的{\em 相對\/}有效性（或者如果簽名有“深度” \(d\)，也可能是 \(d\) 個先前的區塊的相對有效性，參見~\ptref{sp:val.sign.depth}；但這不太影響下面的討論）。換句話說，validator聲稱 shardchain 的下一個狀態 \(s'\) 是通過應用在~\ptref{sp:blk.transf}中描述的區塊評估函數 \(\evblock\) 從先前的狀態 \(s\) 獲得的：
\begin{equation}\label{eq:ev.block.2}
  s'=\evblock(B)(s)
\end{equation}
這樣，如果原始狀態 \(s\) 被證明為“不正確”（例如，由於先前區塊的無效性），那麼簽署了區塊 \(B\) 的validator不能被懲罰。fisherman（參見~\ptref{sp:fish}）只有在發現一個區塊是{\em 相對地\/}無效時才會抱怨。PoS 系統作為一個整體努力使每個區塊都是{\em 相對地\/}有效的，而不是{\em 遞迴地（或絕對地）}有效的。然而，注意到，{\em 如果 blockchain 中的所有區塊都是相對有效的，那麼它們所有的和 blockchain 作為一個整體都是絕對有效的}；使用對 blockchain 的長度的數學歸納法可以輕易地證明這一語句。通過這種方式，輕鬆可驗證的區塊的{\em 相對\/}有效性的聲明一起證明了整個 blockchain 的更強大的{\em 絕對有效性\/}。

注意，通過簽署一個區塊~\(B\)，validator聲稱該區塊給定原始狀態 \(s\) 是有效的（即，~\eqref{eq:ev.block.2}的結果不是值 \(\bot\)，表示下一個狀態不能被計算）。因此，validator必須執行在評估~\eqref{eq:ev.block.2}期間訪問的原始狀態的 cell 的最小形式檢查。

例如，想像一個情境，期望從提交到區塊的交易中訪問的賬戶的原始餘額的 cell 被發現有零個原始字節，而不是期望的 8 或 16。然後，原始餘額簡單地不能從 cell 中檢索，並且在嘗試處理該區塊時會發生“未處理的異常”。在這種情況下，validator不應該簽署這樣的區塊，否則將受到懲罰。

\nxsubpoint \embt(Signing masterchain blocks.)  
與masterchain區塊的情況略有不同：簽署一個masterchain區塊，validator不僅聲明其相對有效性，而且還聲明所有先前區塊的相對有效性，直到這個validator承擔其責任的第一個區塊（但不再往回）。

\nxsubpoint \embt(The total number of validators.)  
validator被選舉的總數的上限 \(T\) （參見~\ptref{sp:global.valid}）在迄今為止描述的系統中，不能超過，例如，幾百或一千，因為所有validator都預計參與BFT共識協議來創建每個新的masterchain區塊，並且尚不清楚這樣的協議是否可以擴展到數千參與者。更重要的是，masterchain區塊必須收集至少三分之二的所有validator（按權益）的簽名，並且這些簽名必須包含在新區塊中（否則系統中的所有其他節點都沒有理由信任新區塊而不自己驗證它）。如果必須在每個masterchain區塊中包括超過，例如，一千個validator簽名，這將意味著每個masterchain區塊中有更多的數據，所有完整節點都要儲存並通過網路傳播，以及花費更多的處理能力來檢查這些簽名（在PoS系統中，完整節點不需要自己驗證區塊，但他們需要相反地檢查validator的簽名）。

雖然將 \(T\) 限制為一千個validator對於TON Blockchain的部署的第一階段似乎足夠了，但必須為未來的增長提供條款，當shardchains的總數變得如此之大，以至於幾百個validator不足以處理所有的shardchains。為此，我們引入了一個額外的可配置參數 \(T'\leq T\)（原本等於~\(T\)），並且只有前 \(T'\) 名被選舉的validator（按權益）預計創建和簽署新的masterchain區塊。


\nxsubpoint \embt(Decentralization of the system.)  
有人可能會懷疑，像TON Blockchain這樣的Proof-of-Stake系統，依賴\(T\approx1000\)的validator來創建所有shardchain和masterchain區塊，是否會變得“太集中”，與像Bitcoin或Ethereum這樣的傳統Proof-of-Work區塊鏈相反，其中每個人（原則上）都可能開採一個新區塊，沒有礦工總數的明確上限。

但是，像Bitcoin和Ethereum這樣的受歡迎的Proof-of-Work區塊鏈，目前需要大量的計算能力（高“hash rates”）以成功的概率開採新區塊。因此，新區塊的開採趨於集中在幾個大玩家手中，他們投資大量資金建立充滿為開採優化的定制硬體的數據中心；以及幾個大型的開採池手中，它們集中並協調了無法自己提供足夠“hash rate”的大量人的努力。

因此，到2017年，超過75％的新Ethereum或Bitcoin區塊由少於十個礦工產生。實際上，兩個最大的Ethereum開採池共同生產了超過一半的所有新區塊！顯然，這樣的系統比依賴\(T\approx1000\)節點生產新區塊的系統更為集中。

人們還可能注意到，成為TON Blockchainvalidator所需的投資——即購買硬體（例如，幾個高性能伺服器）和權益（如有必要，可以通過 nominator pool 輕鬆收集；參見~\ptref{sp:nominators}）——比成為成功的獨立Bitcoin或Ethereum礦工所需的要少。實際上，~\ptref{sp:global.valid}的參數\(L\)將迫使 nominator 不加入最大的“開採池”（即，積累了最大權益的validator），而是尋找目前正在接受 nominator 資金的較小的validator，甚至創建新的validator，因為這將允許更高比例的validator的——並且也是 nominator 的——權益被使用，從而獲得更大的開採獎勵。這種方式，TON Proof-of-Stake系統實際上{\em 鼓勵\/}去中心化（創建和使用更多的validator）並{\em 懲罰\/}集中化。

\nxsubpoint\label{sp:rel.rel} \embt(Relative reliability of a block.)
區塊的{\em (相對) 可靠性\/}簡單地說是已簽署此區塊的所有validator的總權益。換句話說，如果這個區塊被證明是無效的，某些行為者會失去的金額。如果有人關心的交易傳輸值低於區塊的可靠性，可以認為它們足夠安全。從這個意義上說，相對可靠性是外部觀察者可以對特定區塊的信任度的衡量。

注意，我們談論的是區塊的{\em 相對\/}可靠性，因為它保證該區塊是有效的{\em 前提是前一個區塊和所有其他被參考的shardchains'區塊都是有效的\/}（參見~\ptref{sp:abs.val.from.rel}）。

一個區塊的相對可靠性在提交後可能會增加——例如，當遲來的validator的簽名被添加時（參見~\ptref{sp:val.sign.depth}）。另一方面，如果其中一個validator因與其他區塊相關的不當行為而失去部分或全部權益，區塊的相對可靠性可能{\em 減少}。

\nxsubpoint \embt("Strengthening" the blockchain.) 提供驅使validator提高區塊相對可靠性的激勵是很重要的。這樣做的一種方法是為validator分配小量的獎勵，以在其他shardchains的區塊上添加簽名。即使是“即將成為”的validator，他們已存入的股份不足以進入按股份排名前$T$的validator，並被包括在全域validator集合中（參見~\ptref{sp:global.valid}），也可能參與這項活動（如果他們同意在失去選舉後保持其股份凍結，而不是撤回）。這樣的validator可能同時充當fisherman（參見~\ptref{sp:fish}）：如果他們必須檢查某些區塊的有效性，他們也可以選擇報告無效的區塊並收集相關獎勵。

\nxsubpoint\label{sp:rec.rel} \embt(Recursive reliability of a block.) 人們也可以定義一個區塊的{\em recursive reliability\/}，這是其相對可靠性與其引用的所有區塊的遞歸可靠性之間的最小值（即，masterchain區塊、先前的shardchain區塊和一些相鄰shardchains的區塊）。換句話說，如果該區塊被證明是無效的，無論是因為它本身無效還是因為它所依賴的某個區塊無效，至少有人會失去這筆錢。如果人們真的不確定是否信任區塊中的特定交易，人們應該計算這個區塊的{\em recursive\/}可靠性，而不僅僅是{\em relative\/}的可靠性。

當計算遞歸可靠性時，沒有必要回溯太遠，因為如果我們回溯太遠，我們會看到已經解凍並提取的validator簽名的區塊。無論如何，我們不允許validator自動重新考慮那些舊的區塊（即，創建超過兩個月的區塊，如果使用當前的可配置參數的值），並從中創建分叉或使用“垂直blockchains”（參見~\ptref{sp:inv.sh.blk.corr}）修正它們，即使它們被證明是無效的。我們假設兩個月的時期提供了充足的機會來檢測和報告任何無效的區塊，因此如果在這段時期內沒有挑戰某個區塊，那麼它不太可能受到挑戰。

\nxsubpoint \embt(Consequence of Proof-of-Stake for light nodes.)  TON Blockchain 採用的 Proof-of-Stake 方法的一個重要結果是，TON Blockchain 的輕型節點（運行輕型客戶端軟體）不需要下載所有 shardchain 或甚至 masterchain 區塊的「標頭」，以便能夠自行檢查完整節點提供給其的 Merkle 證明，作為對其查詢的回答。

實際上，由於最近的 shardchain 區塊 hash 已包含在 masterchain 區塊中，完整節點可以輕鬆提供一個 Merkle 證明，從已知的 masterchain 區塊的 hash 開始，說明給定的 shardchain 區塊是有效的。接下來，輕型節點只需要知道 masterchain 的第一個區塊（其中宣布了第一組validator），這個區塊（或至少其 hash）可能被內置到客戶端軟體中，並且每個月後只需一個 masterchain 區塊，其中宣布了新當選的validator集合，因為這個區塊將由上一組validator簽署。從那時起，它可以獲得最近的幾個 masterchain 區塊，或至少他們的標頭和validator簽名，並使用它們作為檢查完整節點提供的 Merkle 證明的基礎。

\mysubsection{分割和合併 Shardchains}\label{sect:split.merge}

TON Blockchain 最具特色和獨特的功能之一是，當負載過高時，它能夠自動將 shardchain 分割為兩部分，並在負載下降時將它們合併回來（參見~\ptref{sp:dyn.split.merge}）。由於其獨特性和對整個專案可擴展性的重要性，我們必須詳細討論它。

\nxsubpoint \embt(Shard configuration.)  請回憶，在任何給定的時間點，每個工作鏈 $w$ 都被分割成一個或多個 shardchains $(w,s)$ （參見~\ptref{sp:shard.ident}）。這些 shardchains 可以由一棵二進制樹的葉子表示，其根為 $(w,\emptyset)$，且每個非葉子節點 $(w,s)$ 都有子節點 $(w,s.0)$ 和 $(w,s.1)$。這樣，屬於工作鏈 $w$ 的每個賬戶都被分配到確切的一個 shard，而知道當前的 shardchain 配置的每個人都可以確定包含賬戶 $\accountid$ 的 shard $(w,s)$：它是二進制字符串 $s$ 是 $\accountid$ 前綴的唯一 shard。

shard 配置—即，這個 {\em shard binary tree}，或給定 $w$ 的所有活躍 $(w,s)$ 的集合（對應於 shard binary tree 的葉子）—是 masterchain 狀態的一部分，且對於跟踪 masterchain 的每個人都可用。\footnote{實際上，shard 配置完全由最後的 masterchain 區塊確定；這簡化了獲取 shard 配置的訪問。}

\nxsubpoint \embt(Most recent shard configuration and state.)  回想一下，最近的 shardchain 區塊的 hashes 被包含在每個 masterchain 區塊中。這些 hashes 被組織成一個 shard binary tree（實際上，是每個 workchain 的一系列樹）。這樣，每個 masterchain 區塊都包含最近的 shard 配置。

\nxsubpoint \embt(Announcing and performing changes in the shard configuration.)  shard 配置可以通過兩種方式更改：要麼將 shard $(w,s)$ {\em split\/} 為兩個 shards $(w,s.0)$ 和 $(w,s.1)$，要麼將兩個「sibling」shards $(w,s.0)$ 和 $(w,s.1)$ {\em merged\/} 為一個 shard $(w,s)$。

這些 split/merge 操作在事先（例如，$2^6$；這是一個可配置的參數）的區塊中被宣布，首先在相應的 shardchain 區塊的「標頭」中，然後在引用這些 shardchain 區塊的 masterchain 區塊中。這個提前公告是為了讓所有相關方為計劃的變更做好準備（例如，建立一個 overlay multicast network 來分發新創建的 shardchains 的新區塊，如~\ptref{sect:overlay}所述）。然後，更改首先提交到 shardchain 區塊的（標頭），然後傳播到 masterchain 區塊。這樣，masterchain 區塊不僅定義了在其創建之前的最新 shard 配置，而且還定義了下一個立即的 shard 配置。

\nxsubpoint \embt(validator task groups for new shardchains.)  回憶一下，每個 shard，即每個 shardchain，通常都被分配一個validator的子集（一個 validator task group）專用於在相應的 shardchain 中創建和驗證新區塊（參見~\ptref{sp:val.task.grp}）。這些 task groups 被選為某段時間（大約一小時），並且在提前知道的時間（也大約是一小時），在此期間是不變的。\footnote{除非某些validator因簽署無效的區塊而被臨時或永久禁止，那麼他們將自動從所有 task groups 中被排除。}

但是，實際的 shard 配置可能會在此期間因為 split/merge 操作而發生變化。必須為新創建的 shards 分配 task groups。這是如此完成的：

注意，任何活躍的 shard $(w,s)$ 要麼是某個唯一確定的原始 shard $(w,s')$ 的後代，意味著 $s'$ 是 $s$ 的前綴，要麼它將是原始 shards $(w,s')$ 的子樹的根，其中 $s$ 將是每個 $s'$ 的前綴。在第一種情況下，我們簡單地將原始 shard $(w,s')$ 的 task group 作為新 shard $(w,s)$ 的 task group。在後一種情況下，新 shard $(w,s)$ 的 task group 將是所有原始 shards $(w,s')$ 的 task groups 的聯集，這些 shards 是 shard tree 中的 $(w,s)$ 的後代。

這樣，每個活躍的 shard $(w,s)$ 都被分配了一個明確定義的validator子集（task group）。當一個 shard 被分割時，兩個子節點都繼承了原始 shard 的整個 task group。當兩個 shards 被合併時，它們的 task groups 也被合併。

任何追踪 masterchain 狀態的人都可以計算每個活躍 shard 的validator task groups。


\nxsubpoint \embt(Limit on split/merge operations during the period of
responsibility of original task groups.) 最終，新的 shard 配置將被考慮到，並且新的專用validator子集（task groups）將自動分配給每個 shard。在此之前，必須對 split/merge 操作施加某種限制；否則，如果原始 shard 迅速分裂成 $2^k$ 個新的 shards，則原始 task group 可能最終同時驗證 $2^k$ shardchains，對於大的 $k$。

這是通過對 active shard 配置與原始 shard 配置（目前用於選擇 validator task groups 的配置）之間的距離施加限制來實現的。例如，可能要求從 active shard $(w,s)$ 到原始 shard $(w,s')$ 在 shard tree 中的距離，如果 $s'$ 是 $s$ 的前驅（即 $s'$ 是 binary string $s$ 的前綴），則不得超過3，如果 $s'$ 是 $s$ 的後繼（即 $s$ 是 $s'$ 的前綴），則不得超過2。否則，不允許進行 split 或 merge 操作。

大致上，對於給定的 validator task groups 集合的責任期間，一個 shard 可以被分裂（例如，三次）或合併（例如，兩次）的次數施加了限制。除此之外，合併或分裂創建 shard 之後，某段時間（某些區塊數）內不能重新配置它。

\nxsubpoint\label{sp:split.necess} \embt(Determining the necessity of
split operations.) shardchain 的 split 操作是由某些正式條件觸發的（例如，如果連續64個區塊的 shardchain 區塊至少有 $90\%$ 是滿的）。這些條件由 shardchain task group 監控。如果它們得到滿足，首先在新的 shardchain 區塊的標頭中包含一個「split 準備」標誌（並傳播到引用這個 shardchain 區塊的 masterchain 區塊）。然後，在幾個區塊之後，shardchain 區塊的標頭中包含「split 提交」標誌（並傳播到下一個 masterchain 區塊）。

\nxsubpoint \embt(Performing split operations.) 在 shardchain $(w,s)$ 的區塊 $B$ 中包含「split commit」標誌後，該 shardchain 中不能有後續的區塊 $B'$。相反，將創建 shardchains $(w,s.0)$ 和 $(w,s.1)$ 的兩個區塊 $B'_0$ 和 $B'_1$，分別參考區塊 $B$ 作為它們的前一個區塊（並且它們都將通過標頭中的標誌指示 shard 剛剛被分裂）。下一個 masterchain 區塊將包含新 shardchains 的區塊 $B'_0$ 和 $B'_1$ 的 hashes；它不允許包含 shardchain $(w,s)$ 的新區塊 $B'$ 的 hash，因為「split commit」事件已經被提交到前一個 masterchain 區塊。

請注意，兩個新的 shardchains 將由與舊的 shardchain 相同的 validator task group 驗證，所以它們將自動擁有其狀態的副本。從 Infinite Sharding Paradigm 的角度來看，狀態分裂操作本身相對簡單（參見~\ptref{sp:split.merge.state}）。


\nxsubpoint\label{sp:merge.necess} \embt(Determining the necessity of
merge operations.) 合併 shard 操作的必要性也由某些正式條件檢測 (例如，如果連續64個區塊的兩個兄弟 shardchains 的區塊大小總和不超過最大區塊大小的 $60\%$)。這些正式條件還應考慮這些區塊所消耗的總 gas，並將其與當前的區塊 gas 限制進行比較，否則由於有一些計算密集型的交易阻止了更多交易的納入，區塊可能會偶然變小。

這些條件由兩個兄弟 shards $(w,s.0)$ 和 $(w,s.1)$ 的 validator task groups 監控。請注意，兄弟節點在 hypercube 路由方面必然是鄰居 (參考~\ptref{sp:hypercube})，因此任何 shard 的 task group 的 validators 都將在某種程度上監控兄弟 shard。

當滿足這些條件時，validator 子組之一可以通過發送特殊消息建議另一個合併。然後，它們組合成一個臨時的「合併任務組」，具有組合的成員資格，能夠運行 BFT 共識算法，並在必要時傳播區塊更新和區塊候選者。

如果他們就合併的必要性和準備情況達成共識，「merge prepare」標誌將提交到每個 shardchain 的一些區塊的頭部，並附帶至少三分之二的兄弟 task group 的 validators 的簽名（並被傳播到下一個 masterchain 區塊，以便每個人都可以為即將到來的重新配置做好準備）。但是，他們繼續為一些預定義數量的區塊創建單獨的 shardchain 區塊。

\nxsubpoint \embt(Performing merge operations.) 之後，當來自兩個原始 task groups 的聯合的 validators 準備成為已合併 shardchain 的 validators 時 (這可能涉及從兄弟 shardchain 的狀態轉移和一個狀態合併操作)，他們在其 shardchain 的區塊的頭部提交一個「merge commit」標誌 (這一事件傳播到下一個 masterchain 區塊)，並停止在單獨的 shardchains 中創建新的區塊 (一旦出現 merge commit 標誌，在單獨的 shardchains 中創建區塊是被禁止的)。相反，創建了一個已合併的 shardchain 區塊 (由兩個原始 task groups 的聯合創建)，在其「header」中參考它的兩個「preceding blocks」。這反映在下一個 masterchain 區塊中，該區塊將包含已合併 shardchain 的新創建區塊的 hash。之後，已合併的 task group 繼續在已合併的 shardchain 中創建區塊。

\mysubsection{區塊鏈專案的分類}\label{sect:class.blkch}

我們將通過將 TON 區塊鏈與現有和擬議的區塊鏈專案進行比較，來結束我們對 TON 區塊鏈的簡短討論。但在此之前，我們必須引入一個足夠通用的區塊鏈專案分類。基於此分類的特定區塊鏈專案的比較，將被推遲到~\ptref{sect:compare.blkch}。

\nxsubpoint \embt(Classification of blockchain projects.) 作為第一步，我們建議一些用於區塊鏈（即，對於區塊鏈專案）的分類標準。任何這種分類都是有點不完整和表面的，因為它必須忽略正在考慮的專案的一些最具體和獨特的特點。然而，我們認為這是在提供至少一個非常粗略和大約的區塊鏈專案地圖的必要第一步。

我們考慮的標準列表如下：
\begin{itemize}
\item 單一區塊鏈與多區塊鏈架構 (參見~\ptref{sp:single.multi})
\item 共識算法：Proof-of-Stake 與 Proof-of-Work (參見~\ptref{sp:pow.pos})
\item 對於 Proof-of-Stake 系統，使用的確切的區塊生成、驗證和共識算法（兩個主要選項是 DPOS 與 BFT; 參見~\ptref{sp:dpos.bft}）
\item 對「任意的」(Turing-complete) 智能合約的支持 (參見~\ptref{sp:smartc.supp})
\end{itemize}
多區塊鏈系統有額外的分類標準 (參見~\ptref{sp:class.multichain}):
\begin{itemize}
\item 成員區塊鏈的類型和規則：同質的、異質的 (參見~\ptref{sp:blkch.hom.het})，混合的 (參見~\ptref{sp:mixed.het.hom})。聯邦 (參見~\ptref{sp:het.confed})
\item 有無{\em 主鏈}，內部或外部 (參見~\ptref{sp:pres.masterch})
\item 對 sharding 的原生支持 (參見~\ptref{sp:shard.supp})。靜態或動態 sharding (參見~\ptref{sp:dyn.stat.shard})
\item 成員區塊鏈之間的互動：鬆散聯接和緊密聯接的系統 (參見~\ptref{sp:blkch.interact})
\end{itemize}

\nxsubpoint\label{sp:single.multi} \embt(Single-blockchain vs.\ multi-blockchain projects.) 第一個分類標準是系統中的區塊鏈數量。最古老和最簡單的專案由一個{\em 單一區塊鏈}組成（簡稱「單鏈專案」）；更複雜的專案使用（或更確切地說，計劃使用）{\em 多個區塊鏈}（「多鏈專案」）。

單鏈專案通常更簡單且經過更好的測試；它們經受住了時間的考驗。它們的主要缺點是低性能，或者至少是交易吞吐量，對於通用系統來說，這一數量在十 (Bitcoin) 到不到一百 (Ethereum) 的交易每秒。一些專用系統（如 Bitshares）能夠在區塊鏈狀態適合於記憶體的情況下，處理每秒數萬的專用交易，並將處理限制於一個預定義的特殊交易集，然後由像 C++ 這樣的語言編寫的高度優化的程式碼執行（這裡沒有 VMs）。

多鏈專案提供了每個人都渴望的可擴展性。他們可能支持更大的總狀態和更多的每秒交易，但代價是使專案變得更為複雜，其實施更具挑戰性。因此，已經運行的多鏈專案很少，但大多數擬議的專案都是多鏈的。我們相信未來屬於多鏈專案。


\nxsubpoint\label{sp:pow.pos} \embt(創建和驗證區塊: 工作量證明 vs. 權益證明.) 另一個重要的區別是用於創建和傳播新區塊、檢查其有效性，以及在出現多個分支時選擇其中之一的算法和協議。

兩種最常見的範疇是 {\em Proof-of-Work (PoW)} 和 {\em Proof-of-Stake (PoS)}。工作量證明方法通常允許任何節點創建（“挖掘”）一個新區塊（並獲得與挖掘區塊相關的一些獎勵），前提是它有幸在其他競爭者成功之前解決一個否則無用的計算問題（通常涉及計算大量的hashes）。在出現分支的情況下（例如，如果兩個節點發布兩個否則有效但不同的區塊來跟隨前一個），最長的分支勝出。這樣，區塊鏈的不變性保證是基於生成區塊鏈所花費的{\em 工作量}（計算資源）：任何希望創建此區塊鏈的分支的人都需要重新做這些工作，以創建已提交區塊的替代版本。為此，一個人需要控制超過$50\%$的創建新區塊所花費的總計算能力，否則替代分支變得最長的機會會指數性地降低。

權益證明方法基於一些特殊節點（{\em validator}）所做的大量{\em  stake }（以加密貨幣提名），以斷言它們已經檢查了一些區塊並發現它們是正確的。validator簽署區塊，並因此收到一些小獎勵；但是，如果一個validator被發現簽署了一個不正確的區塊，並且提供了這方面的證據，則其全部或部分 stake 將被沒收。這樣，區塊鏈的有效性和不變性保證是由validator對區塊鏈有效性的總 stake 給出的。

從這個角度看，權益證明更為自然，因為它激勵validator（它們取代了PoW礦工）執行有用的計算（需要檢查或創建新區塊，尤其是執行區塊中列出的所有交易），而不是計算其他無用的hashes。這樣，validator會購買更適合處理用戶交易的硬件，以獲得與這些交易相關的獎勵，從整個系統的角度看，這似乎是一項相當有用的投資。

然而，權益證明系統在實施上有些挑戰，因為必須為許多罕見但可能的情況提供支援。例如，一些惡意的validator可能密謀破壞系統以獲取利益（例如，通過改變自己的加密貨幣餘額）。這導致了一些非常重要的博弈論問題。

簡而言之，權益證明更為自然且更有前景，尤其是對於多區塊鏈專案（因為如果有許多區塊鏈，工作量證明將需要過多的計算資源），但必須更加小心地考慮和實施。大多數目前運行的區塊鏈專案，尤其是最古老的專案（如Bitcoin和至少是原始的Ethereum），使用工作量證明。

\nxsubpoint\label{sp:dpos.bft} \embt(Variants of Proof-of-Stake. DPOS
vs.\ BFT.) 雖然Proof-of-Work算法彼此非常相似，主要差異在於必須計算以挖掘新區塊的hash函數，但Proof-of-Stake算法有更多的可能性。它們自己值得一個子分類。

基本上，人們必須回答關於Proof-of-Stake算法的以下問題：
\begin{itemize}
\item 誰可以產生（“挖掘”）一個新區塊 - 任何完整節點，或只是validator的（相對地）小子集的成員？ (大多數PoS系統要求新區塊由數個指定的validator生成並簽名。)
\item validator是否通過他們的簽名保證區塊的有效性，還是所有完整節點都期望自己驗證所有區塊？ (可擴展的PoS系統必須依賴validator的簽名，而不是要求所有節點驗證所有區塊鏈的所有區塊。)
\item 是否有一個預先知道的指定生產者來生成下一個區塊鏈區塊，這樣其他人就不能代替它產生那個區塊？
\item 新建的區塊最初只由一個validator（其生產者）簽署，還是它必須從一開始就收集大多數validator的簽名？
\end{itemize}

雖然似乎根據這些問題的答案有$2^4$可能的PoS算法類別，但在實踐中，區別主要歸結為兩種主要的PoS方法。事實上，大多數現代的PoS算法，旨在用於可擴展的多鏈系統，在前兩個問題上的答案是相同的：只有validator可以產生新區塊，並且他們保證區塊的有效性，而不要求所有完整節點自己檢查所有區塊的有效性。

至於最後兩個問題，它們的答案被證明是高度相關的，基本上只留下了兩個基本選項：
\begin{itemize}
\item {\em Delegated Proof-of-Stake (DPOS)}：每個區塊都有一個眾所周知的指定生產者；其他人不能生產該區塊；新區塊最初只由其生成的validator簽署。
\item {\em Byzantine Fault Tolerant (BFT)} PoS算法：有一個已知的validator子集，其中任何一個都可以建議一個新區塊；在多個建議的候選區塊中選擇實際的下一個區塊的選擇，必須在被發布到其他節點之前由大多數validator驗證並簽名，這是通過Byzantine Fault Tolerant共識協議的版本來實現的。
\end{itemize}

\nxsubpoint\label{sp:dpos.bft.compare} \embt(Comparison of DPOS and
BFT PoS.) BFT方法的優勢是新產生的區塊從一開始就有大多數validator的簽名證明其有效性。另一個優點是，如果大多數validator正確執行BFT共識協議，則根本不會出現分叉。但另一方面，BFT算法往往相當複雜，並且需要更多的時間讓validator子集達成共識。因此，區塊不能太頻繁地生成。這就是為什麼我們預期TON Blockchain（從這個分類的角度看是一個BFT專案）每五秒只生成一個區塊。在實踐中，這個間隔可能會減少到2-3秒（儘管我們不承諾這一點），但如果validator分散在全球各地，則不會再減少。

DPOS算法的優勢是相當簡單和直接。由於它依賴於預先知道的指定區塊生成者，所以可以非常頻繁地生成新區塊，例如，每兩秒一次，或者甚至每秒一次。\footnote{有些人甚至聲稱DPOS區塊生成時間為半秒，如果validator分散在幾個大陸上，這似乎不太現實。}

然而，DPOS要求所有節點 - 或至少所有validator - 驗證收到的所有區塊，因為生成並簽署新區塊的validator不僅確認了此區塊的相對有效性，還確認了它引用的前一個區塊的有效性，以及在鏈中更遠的所有區塊（也許直到當前validator子集的責任期開始）。當前validator子集上有一個預定的順序，因此每個區塊都有一個指定的生產者（即，預期生成該區塊的validator）；這些指定的生產者按循環方式旋轉。這樣，一個區塊首先只由其生成的validator簽名；然後，當挖掘下一個區塊時，並且其生產者選擇引用此區塊而不是它的前一個區塊（否則它的區塊將位於較短的鏈中，這可能會在未來失去“最長分叉”競賽），下一個區塊的簽名本質上也是對前一個區塊的附加簽名。這樣，一個新區塊逐漸收集更多validator的簽名 - 例如，生成下一個區塊所需的時間內的二十個簽名。一個完整的節點將需要等待這二十個簽名，或者自己驗證區塊，從一個已充分確認的區塊開始（例如，回退二十個區塊），這可能並不容易。

DPOS算法的明顯缺點是，只有在挖掘二十個更多的區塊後，一個新區塊（以及其內部的交易）才能達到相同的信任水平（“遞歸可靠性”如\ptref{sp:rec.rel}中所討論的），而BFT算法則立即提供這種信任水平（例如，二十個簽名）。另一個缺點是，DPOS使用“最長分叉勝出”的方法來切換到其他分叉；如果至少有一些生產者在我們感興趣的那個之後無法生成後續的區塊（或者由於網路分割或複雜的攻擊而未能觀察到這些區塊），這使得分叉相當可能。


我們認為，BFT 方法，雖然在實作上更複雜且產生區塊的間隔時間比DPOS長，但它更適合用於「緊密耦合」(參考~\ptref{sp:blkch.interact})的多鏈系統。因為其他的區塊鏈可以在看到新區塊中的已提交交易（例如，生成給它們的消息）後幾乎立即開始行動，而不必等待20次確認有效性（即，接下來的20個區塊），或者等待接下來的六個區塊以確保沒有分叉出現並自己驗證新區塊（在可擴展的多鏈系統中，驗證其他區塊鏈的區塊可能變得過於繁重）。因此，他們可以在保持高度的可靠性和可用性（參考~\ptref{sp:shard.supp}）的同時達到可擴展性。

另一方面，對於一個「鬆散耦合」的多鏈系統，DPOS可能是一個好選擇，即使區塊鏈之間不需要快速交互，例如，如果每個區塊鏈（「工作鏈」）代表一個單獨的分散式交換，且區塊鏈之間的互動限於從一個工作鏈到另一個的罕見代幣轉移（或者，更准確地說，以接近$1:1$的比率交易住在一個工作鏈中的一個altcoin和另一個）。這就是BitShares計畫實際上所做的事情，它非常成功地使用了DPOS。

總的來說，雖然DPOS可以\emph{生成}新的區塊並且\emph{將交易}快速\emph{包含}進它們（區塊間隔時間較短），但這些交易達到其他區塊鏈和off-chain應用程序所需的信任級別，作為「已提交」和「不可變」的，比在BFT系統中\emph{慢得多}，例如，三十秒%
\footnote{例如，EOS，迄今為止提出的最好的DPOS專案之一，承諾45秒的確認和區塊鏈間的交互延遲（參考~\cite{EOSWP}，「交易確認」和「區塊鏈間通信的延遲」部分）。}
而不是五秒。更快的交易\emph{包含}並不意味著更快的交易\emph{承諾}。如果需要快速的區塊鏈間交互，這可能會成為一個巨大的問題。在這種情況下，人們必須放棄DPOS，而選擇BFT PoS。


\nxsubpoint\label{sp:smartc.supp} \embt(Support for Turing-complete
code in transactions, i.e., essentially arbitrary smart contracts.)
區塊鏈專案通常在他們的區塊中收集一些{\em transactions\/}，這些會以認為有用的方式更改區塊鏈的狀態（例如，從一個賬戶轉移某個加密貨幣金額到另一個賬戶）。有些區塊鏈專案可能只允許一些特定的預定義交易類型（如從一個賬戶到另一個賬戶的值轉移，提供正確的簽名）。其他人可能支持在交易中的一些有限的腳本形式。最後，一些區塊鏈支持在交易中執行任意複雜的程式碼，使系統（至少原則上）能夠支持任意應用程序，只要系統的性能允許。這通常與「圖靈完整虛擬機和腳本語言」（意味著可以在任何其他計算語言中編寫的任何程序都可以重寫以在區塊鏈內部執行），以及「智能合約」（這些是住在區塊鏈中的程序）相關聯。

當然，支持任意智能合約使系統真正靈活。另一方面，這種靈活性是有代價的：這些智能合約的程式碼必須在某個虛擬機上執行，每次有人想創建或驗證一個區塊時，都必須對區塊中的每個交易執行這個操作。與可以通過在像C++這樣的語言中實現它們的處理來優化的預定義和不可變的簡單交易類型的情況相比，這降低了系統的性能。

最終，對於任何通用區塊鏈專案，似乎都希望支持圖靈完整的智能合約;否則，區塊鏈專案的設計者必須預先決定他們的區塊鏈將用於哪些應用程序。實際上，比特幣區塊鏈中對智能合約的支持不足是必須創建新的區塊鏈專案Ethereum的主要原因。

在一個（異質的; cf.~\ptref{sp:blkch.hom.het}）多鏈系統中，人們可以通過在一些區塊鏈（即，工作鏈）中支持圖靈完整的智能合約，以及在其他區塊鏈中支持一小組高度優化的交易，來「兩全其美」。

\nxsubpoint\label{sp:class.multichain} \embt(Classification of
multichain systems.) 到目前為止，這個分類對單鏈和多鏈系統都是有效的。然而，多鏈系統承認幾個更多的分類標準，反映系統中不同的區塊鏈之間的關係。我們現在討論這些標準。

\nxsubpoint\label{sp:blkch.hom.het} \embt(Blockchain types:
homogeneous and heterogeneous systems.) 在多鏈系統中，所有區塊鏈可能本質上都是相同的類型，並且有相同的規則（即，使用相同的交易格式、相同的虛擬機器執行智能合約程式碼、共享相同的加密貨幣等），這種相似性被明確地利用，但每個區塊鏈中的數據都是不同的。在這種情況下，我們說該系統是{\em homogeneous}。否則，不同的區塊鏈（在這種情況下通常被稱為{\em workchains\/}）可以有不同的「規則」。然後我們說系統是{\em heterogeneous}。

\nxsubpoint\label{sp:mixed.het.hom} \embt(Mixed
heterogeneous-homogeneous systems.) 有時我們有一個混合系統，其中存在多個區塊鏈的類型或規則集，但許多具有相同規則的區塊鏈都存在，且這一事實被明確地利用。那麼它是一個混合的{\em heterogeneous-homogeneous system}。據我們所知，TON Blockchain 是這種系統的唯一例子。

\nxsubpoint\label{sp:het.confed} \embt(Heterogeneous systems with
several workchains having the same rules, or {\em confederations}.) 在某些情況下，具有相同規則的多個區塊鏈（work\-chains）可以存在於異質系統中，但它們之間的互動與具有不同規則的區塊鏈之間的互動相同（即，並未明確地利用其相似性）。即使他們似乎使用「相同的」加密貨幣，事實上他們使用不同的「altcoins」（加密貨幣的獨立化身）。有時，人們甚至可以使用接近$1:1$的匯率轉換這些altcoins。然而，我們認為這並不使系統變得均質；它仍然是異質的。我們說具有相同規則的這樣的異質workchains集合是一個{\em confederation}。

雖然製作一個異質系統，允許創建具有相同規則的多個work\-chains（即一個聯邦）可能看起來是建立可擴展系統的便宜方法，但這種方法也有很多缺點。從本質上講，如果有人在許多具有相同規則的workchains中托管一個大型專案，她得到的不是一個大型專案，而是該專案的許多小實例。這就像有一個聊天應用程序（或遊戲）只允許每個聊天（或遊戲）房間有最多50名成員，但「擴展」通過創建新房間在必要時容納更多用戶。結果，許多用戶可以參加聊天或遊戲，但我們能說這樣的系統真的可擴展嗎？

\nxsubpoint\label{sp:pres.masterch} \embt(Presence of a masterchain,
external or internal.) 有時，一個多鏈計畫有一個特殊的「masterchain」（有時被稱為「控制區塊鏈」），用於儲存系統的整體配置（所有活躍的區塊鏈集合，或更準確地說是workchains）、當前的validator集合（對於一個Proof-of-Stake系統）等。有時其他的區塊鏈被「綁定」到masterchain，例如通過將它們最新的區塊的hash值提交到它（TON Blockchain也是這麼做的）。

在某些情況下，masterchain是{\em external}，這意味著它不是該計畫的一部分，而是一個原先完全與其無關的區塊鏈，對於新計畫的使用並不知情。例如，人們可以嘗試使用Ethereum區塊鏈作為一個外部計畫的masterchain，並為此目的在Ethereum區塊鏈上發布特殊的智能合約（例如，用於選舉和懲罰validator）。

\nxsubpoint\label{sp:shard.supp} \embt(Sharding support.) 有些區塊鏈計畫（或系統）有原生的支持{\em sharding}，這意味著幾個（必然是homogeneous；參見~\ptref{sp:blkch.hom.het}）區塊鏈被視為單一（從高級角度看）虛擬區塊鏈的{\em shards\/}。例如，人們可以創建256個具有相同規則的shard區塊鏈（「shardchains」），並根據其$\accountid$的第一個字節來確定帳戶的狀態。

Sharding是擴展區塊鏈系統的自然方法，因為，如果正確實施，系統中的用戶和智能合約根本不需要知道sharding的存在。事實上，當負載過高時，人們經常希望在現有的單鏈計畫（如Ethereum）中添加sharding。

另一種擴展方法是使用在~\ptref{sp:het.confed}中描述的異質workchains的「聯邦」，允許每個用戶在一個或多個她選擇的workchains中保留她的帳戶，並在必要時將資金從一個workchain轉移到另一個workchain，基本上進行$1:1$的altcoin交換操作。此方法的缺點已在~\ptref{sp:het.confed}中討論過。

但是，sharding不容易在快速和可靠的方式中實施，因為它意味著不同的shardchains之間有很多消息。例如，如果帳戶在$N$個shards之間均勻分佈，且唯一的交易是從一個帳戶到另一個帳戶的簡單資金轉移，那麼所有交易的只有一小部分（$1/N$）將在單一的區塊鏈中執行；幾乎所有的（$1-1/N$）交易將涉及兩個區塊鏈，需要跨區塊鏈的通信。如果我們希望這些交易快速，我們需要一個用於在shardchains之間傳輸消息的快速系統。換句話說，區塊鏈計畫需要在~\ptref{sp:blkch.interact}中描述的意義上是「緊密耦合的」。

\nxsubpoint\label{sp:dyn.stat.shard} \embt(Dynamic and static sharding.)  分片可能是{\em dynamic\/}（當需要時自動創建額外的分片）或是{\em static\/}（有預先定義的分片數量，最好只能通過硬分叉來改變）。大多數分片提議都是靜態的；而TON Blockchain使用的是動態分片（參見~\ptref{sect:split.merge}）。

\nxsubpoint\label{sp:blkch.interact} \embt(Interaction between blockchains: loosely-coupled and tightly-coupled systems.) 多區塊鏈專案可以根據組件區塊鏈之間支持的互動水平進行分類。

最低的支持水平是不同區塊鏈之間完全沒有任何互動。我們在這裡不考慮這種情況，因為我們寧願說這些區塊鏈不是一個區塊鏈系統的部分，而只是相同區塊鏈協議的單獨實例。

下一個支持水平是缺乏對區塊鏈之間的消息傳送的任何具體支持，使得原則上可能進行互動，但很尷尬。我們稱這樣的系統為「鬆散耦合」；在這些系統中，人們必須像發送消息和轉移價值一樣，好像它們是屬於完全獨立的區塊鏈專案的區塊鏈（例如，比特幣和以太坊；想像兩方希望將儲存在比特幣區塊鏈中的比特幣兌換成儲存在以太坊區塊鏈中的以太）。換句話說，必須在源區塊鏈的區塊中包括出站消息（或其生成交易）。然後她（或其他某方）必須等待足夠的確認（例如，後續區塊的給定數量），以認為原始交易已被「提交」並「不可變」，從而能夠根據其存在執行外部操作。只有在此之後，才可以提交將消息中繼到目標區塊鏈的交易（也許還帶有源交易的參考和Merkle存在證明）。

如果在傳輸消息之前沒有等待足夠的時間，或者由於某些其他原因發生了分叉，那麼兩個區塊鏈的聯合狀態將被證明是不一致的：一條消息被遞送到第二個區塊鏈，而該消息從未在第一個區塊鏈中生成（最終選擇的分叉）。

有時會添加對消息傳送的部分支持，通過標准化所有工作鏈區塊中的消息格式和輸入和輸出消息隊列的位置（這在異構系統中尤其有用）。雖然這在某種程度上促進了消息傳遞，但在概念上與之前的情況沒有太大區別，所以這樣的系統仍然是「鬆散耦合」的。

相反，「緊密耦合」的系統包括特殊的機制，以提供所有區塊鏈之間的快速消息傳遞。期望的行為是能夠在生成源區塊鏈的區塊之後立即將消息遞送到另一個工作鏈。另一方面，「緊密耦合」的系統還應該在出現分叉的情況下維護整體的一致性。儘管這兩個要求乍看之下似乎是矛盾的，但我們相信TON Blockchain使用的機制（將shardchain區塊hash包含到masterchain區塊中；使用「垂直」區塊鏈來修復無效的區塊，參見~\ptref{sp:inv.sh.blk.corr}；超立方體路由，參見~\ptref{sp:hypercube}；即時超立方體路由，參見~\ptref{sp:instant.hypercube}）使其成為一個「緊密耦合」的系統，也許是迄今為止唯一的系統。

當然，建立一個「鬆散耦合」的系統要簡單得多；但是，快速和高效的分片（參見~\ptref{sp:shard.supp}）要求系統是「緊密耦合」的。

\nxsubpoint\label{sp:blkch.gen} \embt(Simplified
classification. Generations of blockchain projects.)  我們到目前為止建議的分類方式將所有區塊鏈專案分割成多個類別。然而，我們使用的分類準則在實踐中確實具有很大的相關性。這使我們能夠提議一種簡化的「世代」方式來分類區塊鏈專案，作為現實的一個大略的估計，並給出一些例子。尚未被實施和部署的專案以{\em italics}表示；每一代的最重要特徵都用{\bf bold}顯示。
\begin{itemize}
\item 第一代：單鏈，{\bf PoW}，不支持智能合約。範例：Bitcoin (2009) 和許多其他不那麼有趣的仿造者（如Litecoin、Monero等）。
\item 第二代：單鏈，PoW，{\bf 支援智能合約}。範例：Ethereum (2013; 2015年部署)，至少在它的原始形式中。
\item 第三代：單鏈，{\bf PoS}，支援智能合約。範例：{\em 未來的Ethereum} (2018或之後)。
\item 替代的第三代($3'$)：{\bf 多鏈}，PoS，不支持智能合約，鬆散耦合。範例：Bitshares (2013--2014; 使用DPOS)。
\item 第四代：{\bf 多鏈，PoS，支持智能合約}，鬆散耦合。範例：{\em EOS\/} (2017; 使用DPOS)，{\em PolkaDot\/} (2016; 使用BFT)。
\item 第五代：多鏈，使用BFT的PoS，支援智能合約，{\bf 緊密耦合，具有分片功能}。範例：{\em TON\/} (2017)。
\end{itemize}
儘管並非所有區塊鏈專案都確切地落入這些類別中，但大多數確實如此。


\nxsubpoint\label{sp:genome.change.never} \embt(Complications of
changing the ``genome'' of a blockchain project.) 上述分類定義了區塊鏈專案的「基因組」。這個基因組非常「固定」：一旦專案部署並被許多人使用，就幾乎不可能更改它。更改它需要一系列的硬分叉（這需要社區的大部分人批准），即使如此，更改還需要非常保守，以保持向後兼容性（例如，更改虛擬機的語義可能會破壞現有的智能合約）。另一種方法是創建具有不同規則的新「側鏈」，並將它們以某種方式綁定到原始專案的區塊鏈（或區塊鏈）。人們可能使用現有單區塊鏈專案的區塊鏈作為本質上新的和獨立專案的外部主鏈。\footnote{例如，Plasma專案計劃使用Ethereum區塊鏈作為其（外部）主鏈；它與Ethereum的其他部分互動不多，且可能由與Ethereum專案無關的團隊提議和實施。}

我們的結論是，一旦部署了專案的基因組，就很難更改它。即使從PoW開始，並計劃在未來用PoS替換它，也相當複雜。\footnote{到2017年為止，Ethereum仍在努力從PoW過渡到結合的PoW+PoS系統；我們希望它將來會成為一個真正的PoS系統。} 為原始設計不支持它們的專案添加分片似乎幾乎不可能。\footnote{Ethereum的分片提議可以追溯到2015年；目前還不清楚它們如何被實施和部署，而不會破壞Ethereum或創建一個本質上獨立的平行專案。} 實際上，將智能合約的支持添加到一個（即Bitcoin）原始設計不支持這些功能的專案中被認為是不可能的（或至少被Bitcoin社區的大多數人認為是不受期望的），最終導致了一個新的區塊鏈專案，Ethereum。


\nxsubpoint \embt(Genome of the TON Blockchain.) 因此，如果想建立一個可擴展的區塊鏈系統，必須從一開始就仔細選擇其基因組。如果系統在部署時未知但預期在未來支持一些特定功能，那麼它應該從一開始就支持「異質」工作鏈（可能具有不同的規則）。為了讓系統真正可擴展，它必須從一開始就支持分片；只有當系統是「緊密耦合」時，分片才有意義（參考\ptref{sp:blkch.interact}），因此這反過來意味著存在主鏈，快速的區塊鏈間消息系統，BFT PoS的使用等。

考慮到所有這些含義，為TON區塊鏈專案做出的大多數設計選擇似乎都是自然的，幾乎是唯一可能的選擇。

\mysubsection{與其他區塊鏈專案的比較}\label{sect:compare.blkch}

我們試圖在包含現有和建議的區塊鏈專案的地圖上為其找到位置，從而總結對TON區塊鏈及其最重要和獨特功能的簡要討論。我們使用在\ptref{sect:class.blkch}中描述的分類標準以統一的方式討論不同的區塊鏈專案，並建構這樣一個「區塊鏈專案地圖」。我們將此地圖表示為Table~\ref{tab:blkch.proj}，然後簡要地單獨討論幾個專案，以指出它們可能不適合一般計劃的特殊性。

\begin{table}
  \captionsetup{font=scriptsize}
  \begin{tabular}{|c|cc|ccc|ccc|}
    \hline 專案 & 年份 & 世代 & 共識 & 智能 & 鏈 & 類型 & 分片 & 交互 \\ 
    \hline Bitcoin & 2009 & 1 & PoW & 無 & 1 \\ 
    Ethereum & 2013, 2015 & 2 & PoW & 是 & 1 \\ 
    NXT & 2014 & 2+ & PoS & 無 & 1 \\ 
    Tezos & 2017, ? & 2+ & PoS & 是 & 1 \\ 
    Casper & 2015, (2017) & 3 & PoW/PoS & 是 & 1 \\ 
    \hline BitShares & 2013, 2014 & $3'$ & DPoS & 無 & m & ht. & 無 & L \\ 
    EOS & 2016, (2018) & 4 & DPoS & 是 & m & ht. & 無 & L \\ 
    PolkaDot & 2016, (2019) & 4 & PoS BFT & 是 & m & ht. & 無 & L \\ 
    Cosmos & 2017, ?  & 4 & PoS BFT & 是 & m & ht. & 無 & L \\ 
    TON & 2017, (2018) & 5 & PoS BFT & 是 & m & 混合 & dyn. & T \\ 
    \hline
  \end{tabular}
  \caption{一些值得注意的區塊鏈專案的摘要。各列分別為：{\em 專案} — 專案名稱；{\em 年份} — 宣布年份和部署年份；{\em 世代} — 世代 (參考\ptref{sp:blkch.gen})；{\em 共識} — 共識算法 (參考\ptref{sp:pow.pos} 和\ptref{sp:dpos.bft})；{\em 智能} — 支持任意程式碼（智能合約；參考\ptref{sp:smartc.supp}）；{\em 鏈} — 單/多區塊鏈系統 (參考\ptref{sp:single.multi})；{\em 類型} — 異質/同質多鏈系統 (參考\ptref{sp:blkch.hom.het})；{\em 分片} — 支持分片 (參考\ptref{sp:shard.supp})；{\em 交互} — 區塊鏈間的交互，(L)緩和 或 (T)緊密 (參考\ptref{sp:blkch.interact})。}
  \label{tab:blkch.proj}
\end{table}


\nxsubpoint \embt(Bitcoin \cite{BitcWP}; \url{https://bitcoin.org/}.)
            {\em Bitcoin\/} (2009) 是第一個且最知名的區塊鏈專案。它是典型的{\em 第一代}區塊鏈專案：它是單一鏈，使用工作量證明(Proof-of-Work)與「最長分支勝出」的分支選擇算法，並且沒有圖靈完整的腳本語言（但是，支持沒有循環的簡單腳本）。Bitcoin的區塊鏈沒有帳戶的概念；它使用UTXO（未花費的交易輸出）模型。

\nxsubpoint \embt(Ethereum \cite{EthWP}; \url{https://ethereum.org/}.)
            {\em Ethereum\/} (2015) 是第一個支持圖靈完整智能合約的區塊鏈。因此，它是典型的{\em 第二代\/}專案，且是其中最受歡迎的。它在單一區塊鏈上使用工作量證明，但擁有智能合約和帳戶。

\nxsubpoint \embt(NXT; \url{https://nxtplatform.org/}.)  {\em NXT\/}
(2014) 是第一個基於權益證明(PoS)的區塊鏈和貨幣。它仍然是單鏈，並且不支持智能合約。

\nxsubpoint \embt(Tezos; \url{https://www.tezos.com/}.)  {\em Tezos\/}
(2018或之後) 是一個建議的基於PoS的單一區塊鏈專案。我們在這裡提到它是因為它的獨特功能：其區塊解釋函數$\evblock$（參考\ptref{sp:blk.transf}）不是固定的，而是由一個OCaml模組決定，該模組可以通過在區塊鏈中提交一個新版本（並為所提議的更改收集一些票據）來升級。通過這種方式，一個人將能夠通過首先部署一個「原始」的Tezos區塊鏈，然後逐步地將區塊解釋函數更改為所需的方向，而無需硬分支。

這個想法，儘管引人入勝，但它有一個明顯的缺點，那就是它禁止在其他語言（如C++）中的任何優化實現，因此基於Tezos的區塊鏈註定性能較低。我們認為，可能已經通過發布所提議的區塊解釋函數$\evtrans$的正式{\em 規範}來獲得類似的結果，而不是確定特定的{\em 實現}。

\nxsubpoint
\embt(Casper.)%
\footnote{\url{https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/}}
{\em Casper\/} 是Ethereum的即將到來的PoS算法；如果在2017年（或2018年）的逐步部署成功，它將使Ethereum變成一個帶有智能合約支持的單鏈PoS或混合PoW+PoS系統，將Ethereum轉化為{\em 第三代\/}專案。

\nxsubpoint \embt(BitShares \cite{BitShWP}; \url{https://bitshares.org}.)
            {\em BitShares\/} (2014) 是一個為分散式基於區塊鏈的交易所提供的平台。這是一個異構的多區塊鏈DPoS系統，且不帶有智能合約；它透過僅允許一小部分預先定義的專用交易類型來實現其高性能，這些交易類型可以在C++中有效地實現，前提是區塊鏈狀態適合於記憶體中。這也是第一個使用委託權益證明(Delegated Proof-of-Stake, DPoS)的區塊鏈專案，至少為某些專用目的證明其可行性。

\nxsubpoint\label{sp:discuss.EOS} \embt(EOS \cite{EOSWP}; \url{https://eos.io}.)
            {\em EOS\/} (2018或以後) 是一個建議的異構多區塊鏈DPoS系統，{\em 並帶有\/}智能合約支持和一些最小的消息傳遞支持（在\ptref{sp:blkch.interact}描述的意義上仍然是鬆散連接的）。這是先前成功創建了BitShares和SteemIt專案的同一團隊的嘗試，展示了DPoS共識算法的強大之處。通過為需要它的專案創建專用的工作鏈（例如，一個分散式交易所可能使用一個支持一組專用的優化交易的工作鏈，類似於BitShares所做的那樣）以及創建具有相同規則的多個工作鏈來實現可伸縮性（在\ptref{sp:het.confed}描述的意義上是{\em 聯邦\/}）。這種可伸縮性方法的缺點和限制已在{\em loc.~cit.}中討論。另見\ptref{sp:dpos.bft.compare}、\ptref{sp:shard.supp}和\ptref{sp:blkch.interact}，進一步討論DPoS、分片、工作鏈之間的互動及其對區塊鏈系統的可伸縮性的影響。

    與此同時，即使一個人不能在區塊鏈內「創建一個Facebook」（參見\ptref{sp:blockchain.facebook}），不論是EOS還是其他方式，我們認為EOS可能會成為某些高度專用的弱互動分散式應用程序的便利平台，類似於BitShares（去中心化交易所）和SteemIt（去中心化博客平台）。

\nxsubpoint\label{sp:discuss.PolkaDot} \embt(PolkaDot \cite{PolkaWP}; \url{https://polkadot.io/}.)
            {\em PolkaDot\/} (2019或之後) 是最佳思考且最詳細的建議多鏈權益證明專案之一；其開發是由Ethereum的共同創辦人之一領導的。此專案是我們地圖上與TON Blockchain最接近的專案。（事實上，我們的「fisherman」和「nominator」術語都是歸功於PolkaDot專案。）

PolkaDot是一個異構的鬆散連接的多鏈權益證明專案，具有用於生成新區塊的拜占庭容錯（BFT）共識和主鏈（可能是外部的，例如Ethereum區塊鏈）。它還使用超立方體路由，有點像TON的慢速版本，如\ptref{sp:hypercube}所述。

其獨特的功能是它不僅可以創建{\em 公共的}，而且還可以創建{\em 私有的\/}區塊鏈。這些私有區塊鏈也將能夠與其他公共區塊鏈互動，不論是PolkaDot還是其他的。

因此，PolkaDot可能會成為大規模{\em 私有\/}區塊鏈的平台，例如，銀行聯盟可能會使用它來快速相互轉賬，或者大型公司可能對私有區塊鏈技術有其他用途。

然而，PolkaDot不支持分片且不是緊密連接的。這在某種程度上限制了其可伸縮性，與EOS相似。（或許稍好一些，因為PolkaDot使用BFT PoS而非DPoS。）

\nxsubpoint \embt(Universa; \url{https://universa.io}.)  
我們之所以在此提及這個不尋常的區塊鏈專案，是因為它是到目前為止唯一隨便提到與我們的Infinite Sharding Paradigm相似的專案（參見~\ptref{sp:ISP}）。其另一個特點是它通過承諾只有專案的受信任和持有許可的夥伴才會被錄取為validator，因此他們永遠不會提交無效的區塊，來繞過所有與Byzantine Fault Tolerance相關的複雜性。這是一個有趣的決定；但是，它本質上使一個區塊鏈專案故意變得{\em 集中化}，這是區塊鏈專案通常想要避免的（在一個受信任的集中化環境中為什麼需要區塊鏈？）。

\nxsubpoint \embt(Plasma; \url{https://plasma.io}).)  
{\em Plasma\/} (2019?)是Ethereum的另一位共同創辦人的非傳統區塊鏈專案。它旨在緩解Ethereum的某些限制，而不引入sharding。本質上，它是一個與Ethereum分開的專案，引入了一系列的（異構的）workchains，與最高級別的Ethereum區塊鏈綁定（作為一個外部masterchain）。資金可以從層次結構中的任何區塊鏈轉移出去（從Ethereum區塊鏈作為根開始），並伴隨一個要完成的工作描述。然後在子workchain中進行必要的計算（可能需要將原始工作的部分進一步轉發到樹的下方），其結果被傳遞上去，並收集獎勵。通過一個（由payment channel啟發的）機制來避免實現這些workchains的一致性和驗證的問題，該機制允許用戶從一個行為不端的workchain單方面撤回他們的資金到其父workchain（儘管很慢），並重新分配他們的資金和工作到另一個workchain。

因此，Plasma可能成為綁定到Ethereum區塊鏈的分散式計算平台，就像一個``數學協處理器''。但是，這似乎不像是實現真正的通用可伸縮性的方法。

\nxsubpoint \embt(Specialized blockchain projects.)  
還有一些專門的區塊鏈專案，如FileCoin（一個激勵用戶為儲存願意支付費用的其他用戶的文件提供硬碟空間的系統），Golem（一個基於區塊鏈的平台，用於租用和出借計算能力給專門的應用，如3D-rendering）或SONM（另一個類似的計算能力出借專案）。這類專案在區塊鏈組織的層面上沒有引入任何概念上的新事物；相反，它們是特定的區塊鏈應用，可以由運行在通用目的區塊鏈中的智能合約實現，只要它可以提供所需的性能。因此，這類專案可能會使用現有或計劃中的區塊鏈專案作為其基礎，如EOS、PolkaDot或TON。如果一個專案需要``真正的''可伸縮性（基於sharding），那麼它最好使用TON；如果它滿足於在一個``聯邦''背景下工作，通過為其目的明確定義一系列的workchains，它可能會選擇EOS或PolkaDot。

\nxsubpoint \embt(The TON Blockchain.)  
TON（The Open Network）Block\-chain（計劃於2018年）是我們在本文檔中描述的專案。它旨在成為第一個第五代區塊鏈專案——即BFT PoS多鏈專案，混合同質/異質性，支援（可shardable）的自定義workchains，具有原生的sharding支援，並且緊密耦合（特別是，能夠在保持所有shardchains的一致狀態時，幾乎立即轉發shards之間的消息）。因此，它將是一個真正可伸縮的通用區塊鏈專案，能夠容納基本上可以在區塊鏈中實現的任何應用程序。當由TON Project的其他組件增強時（參見~\ptref{sect:ton.components}），其可能性甚至更大。

\nxsubpoint\label{sp:blockchain.facebook} \embtx(Is it possible to
``upload Facebook into a blockchain''?)  
有時候人們聲稱，將Facebook這樣規模的社交網路作為分佈式應用程序部署在區塊鏈中是可能的。通常會引用一個受喜愛的區塊鏈專案作為這種應用的可能“主機”。

我們不能說這是技術上的不可能。當然，需要一個緊密耦合的區塊鏈專案，具有真正的sharding（即TON），以便這種大型應用不會運行得太慢（例如，從一個shardchain中的用戶傳送消息和更新到另一個shardchain中的朋友，且延遲合理）。然而，我們認為這是不需要的，且永遠不會被完成，因為價格會過高。

讓我們考慮將“將Facebook上載到區塊鏈”作為一個思考實驗；任何其他相似規模的專案也可能作為一個示例。一旦Facebook被上載到區塊鏈，目前由Facebook的伺服器完成的所有操作將被序列化為某些區塊鏈的交易（例如，TON的shardchains），並將由這些區塊鏈的所有validator執行。每項操作都必須執行，比如說，至少20次，如果我們希望每個區塊至少收集20個validator簽名（立即或最終，如在DPOS系統中）。同樣，Facebook伺服器在其硬碟上保留的所有數據將被保留在相應shardchain的所有validator的硬碟上（即，至少有20份副本）。

因為validator基本上是與Facebook目前使用的相同伺服器（或許是伺服器集群，但這不影響此論點的有效性），我們可以看出，將Facebook運行在blockchain中的總硬件開銷至少比傳統方式實現高出20倍。

事實上，開銷還會更高，因為blockchain的虛擬機比運行優化編譯程式碼的“裸CPU”要慢，且其儲存未針對Facebook特定的問題進行優化。通過為Facebook設計具有某些特殊交易的特定workchain，可以部分地減輕此問題；這是BitShares和EOS實現高性能的方法，也可在TON Blockchain中使用。然而，一般的blockchain設計本身仍然會帶來一些額外的限制，例如需要將所有操作註冊為block中的交易，將這些交易組織成Merkle tree，計算和檢查它們的Merkle hashes，進一步傳播這個block等。

因此，保守估計是，為了驗證承載該規模社交網路的blockchain專案，需要的伺服器性能是Facebook現在使用的伺服器的100倍。有人將不得不為這些伺服器付錢，無論是擁有分散應用的公司（想像一下每個Facebook頁面上有700條廣告，而不是7條）還是它的用戶。無論哪種方式，這在經濟上似乎都不可行。

我們認為，{\em 不是所有東西都應該上載到blockchain中}。例如，不必在blockchain中保留用戶照片；將這些照片的hashes註冊到blockchain中，並將照片保存在分散的off-chain儲存（例如FileCoin或TON Storage）中，可能是更好的選擇。這就是為什麼TON不僅僅是一個blockchain專案，而是圍繞TON Blockchain為中心的幾個組件的集合，如Chapters~\ptref{sect:ton.components}和~\ptref{sect:services}所概述的。


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%                  NETWORK
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\clearpage
\mysection{TON 網路協議}\label{sect:network}

任何 blockchain 專案不僅需要 block 格式和 blockchain 驗證規則的規範，還需要一個用於傳播新 block、發送和收集交易候選資料等的網路協議。換句話說，每個 blockchain 專案都必須設置一個專門的點對點網路。這個網路必須是點對點的，因為通常希望 blockchain 專案是分散式的，所以不能依賴於一組集中式的伺服器並使用傳統的客戶端-伺服器架構，例如，傳統的網路銀行應用程序所做的。即使是輕量級客戶端（例如，輕量級加密貨幣錢包智能型手機應用程序），它們必須以客戶端-伺服器的方式連接到完整節點，如果先前的節點停止運作，實際上它們可以自由地連接到另一個完整節點，只要用於連接到完整節點的協議足夠標準化。

雖然如 Bitcoin 或 Ethereum 這樣的單一 blockchain 專案的網路需求可以很容易地被滿足（基本上需要構建一個“隨機”點對點的覆蓋網路，並通過一個 gossip 協議傳播所有新的 block 和交易候選資料），但像 TON Blockchain 這樣的多 blockchain 專案則要求更高（例如，人們必須能夠訂閱只有某些 shardchains 的更新，而不一定是所有的）。因此，TON Blockchain 和整個 TON 專案的網路部分至少值得簡短的討論。

另一方面，一旦需要支持 TON Blockchain 的更為複雜的網路協議到位，事實證明它們可以很容易地用於不一定與 TON Blockchain 的直接需求相關的目的，從而為 TON 生態系統中創建新服務提供了更多的可能性和靈活性。

\mysubsection{抽象數據報網路層}\label{sect:ANL}

建立 TON 網路協議的基石是{\em (TON) Abstract (Datagram) Network Layer}。它使所有節點能夠假設某些“網路身份”，由 256 位“抽象網路地址”表示，並僅使用這些 256 位網路地址來識別發件人和收件人進行通信（首先互相發送數據報）。尤其是，人們不需要擔心 IPv4 或 IPv6 地址、UDP 端口號等；它們由 Abstract Network Layer 隱藏。


\clearpage
\mysection{TON 網路協議}\label{sect:network}

\nxsubpoint\label{sp:abs.addr} \embt(Abstract network addresses.)
一個{\em abstract network address}，或稱為{\em abstract address}，或簡稱為{\em address\/}，是一個 256 位整數，基本上等同於 256 位 ECC 公鑰。此公鑰可以任意生成，因此節點可以根據喜好創建許多不同的網路身份。但是，為了接收（和解密）針對此地址的消息，人們必須知道相對應的{\em private\/}密鑰。

實際上，地址{\em 不是\/}公鑰本身；而是一個序列化 TL-object (參見~\ptref{sp:TL})的 256 位 hash（$\Hash=\Sha$），這可以根據其建構子（前四位元組）描述多種類型的公鑰和地址。在最簡單的情況下，此序列化 TL-object 僅由一個 4 位元組魔法數字和一個 256 位橢圓曲線密碼學（ECC）公鑰組成；在此情況下，地址將等於這 36 位元組結構的 hash。然而，人們也可以使用 2048 位 RSA 鑰匙或任何其他公鑰密碼學方案。

當一個節點獲知另一個節點的抽象地址時，它還必須接收其「原像」（即，其 hash 等於該抽象地址的序列化 TL-object）；否則，它將無法加密並發送數據報到該地址。

\nxsubpoint \embt(Lower-level networks. UDP implementation.)  
從幾乎所有 TON Networking 組件的角度看，唯一存在的就是一個網路（Abstract Datagram Networking Layer），能夠（不可靠地）從一個抽象地址發送數據報到另一個抽象地址。原則上，Abstract Datagram Networking Layer (ADNL) 可以在不同的現有網路技術上實施。但是，我們打算在 IPv4/IPv6 網路（如互聯網或內部網）上實施它，並在 UDP 不可用時選用 TCP 作為備選。

\nxsubpoint\label{sp:net.simple.dg} \embt(Simplest case of ADNL over UDP.)  
通過 UDP 從發送者的抽象地址發送數據報到任何其他抽象地址（已知原像）的最簡單情況可以如下實施。

假設發送者以某種方式知道擁有目標抽象地址的接收者的 IP 地址和 UDP 端口，且接收者和發送者都使用從 256 位 ECC 公鑰派生的抽象地址。

在此情況下，發送者簡單地通過其 ECC 簽名（用其私鑰完成）和其源地址（或源地址的原像，如果接收者還不知道該原像）增強要發送的數據報。結果使用收件人的公鑰加密，嵌入到一個 UDP 數據報中並發送到收件人已知的 IP 和端口。因為 UDP 數據報的前 256 位包含接收者的抽象地址，所以接收者可以確定應該使用哪個私鑰來解密數據報的其餘部分。只有在此之後，發送者的身份才被揭示。

\nxsubpoint\label{sp:net.simplest.dg} \embt(Less secure way, with the
sender's address in plaintext.)  有時，一個較不安全的方案就足夠了，當收件人和寄件人的地址在UDP數據報中保持為明文；寄件人的私鑰和收件人的公鑰使用ECDH（橢圓曲線Diffie--Hellman）合併在一起，生成一個256位共享秘密，之後，該共享秘密與明文部分也包含的隨機256位nonce一起用來派生用於加密的AES密鑰。完整性可以通過在加密前將原始明文數據的hash連接到明文來提供。

這種方法的優點是，如果預計兩個地址之間將交換多個數據報，則只需計算一次共享秘密然後將其緩存；然後加密或解密下一個數據報時不再需要較慢的橢圓曲線操作。

\nxsubpoint\label{sp:net.channels} \embt(Channels and channel
identifiers.)  在最簡單的情況下，攜帶內嵌TON ADNL數據報的UDP數據報的前256位將等於收件人的地址。然而，一般來說它們組成了一個{\em channel identifier}。有不同類型的channels。其中一些是點對點的；它們由希望在將來交換大量數據的兩方創建，並通過交換幾個加密數據報（如\ptref{sp:net.simple.dg}或\ptref{sp:net.simplest.dg}中所描述的那樣），運行經典或橢圓曲線Diffie--Hellman（如果需要額外的安全性），或者僅由一方生成隨機共享秘密並將其發送給另一方。

此後，channel identifier由共享秘密和一些額外數據（例如寄件人和收件人的地址）組合而來，例如通過hashing，並且該identifier用作攜帶使用該共享秘密加密的數據的UDP數據報的前256位。

\nxsubpoint\label{sp:tunnels} \embt(Channel as a tunnel identifier.)
一般而言，``channel''或``channel identifier''僅選擇了接收者已知的處理入站UDP數據報的方法。如果channel是接收者的抽象地址，則處理的方式如\ptref{sp:net.simple.dg}或\ptref{sp:net.simplest.dg}中所述；如果channel是\ptref{sp:net.channels}中討論的已建立的點對點channel，則處理包括使用共享秘密的幫助解密數據報，如{\em loc.~cit.}中所解釋的，等等。

特別地，channel identifier實際上可以選擇一個``tunnel''，當立即的接收者僅將接收到的消息轉發給其他人---實際的接收者或另一個代理時。沿途可能會進行一些加密或解密步驟（讓人想起``onion routing'' \cite{Onion}或甚至``garlic routing''\footnote{\url{https://geti2p.net/en/docs/how/garlic-routing}}），並且可能使用另一個channel identifier用於重新加密的轉發數據包（例如，點對點channel可以用於將數據包轉發給路徑上的下一個接收者）。

通過這種方式，可以在TON Abstract Datagram Network Layer的層次上添加對``tunneling''和``proxying''的支持---與TOR或$I^2P$專案提供的相似---而不影響所有高級TON network protocols的功能，它們將不知道這樣的添加。此機會被{\em TON Proxy\/}服務所利用（參見\ptref{sp:ex.ton.proxy}）。


\nxsubpoint\label{sp:net.startup} \embt(Zero channel and the bootstrap
problem.)  通常，一個TON ADNL節點會有一些``neighbor table''，其中包含有關其他已知節點的信息，例如它們的抽象地址、它們的preimages（即，公鑰）及它們的IP地址和UDP端口。然後，它將逐步擴展此表格，使用從這些已知節點作為特殊查詢的回答所學到的信息，並有時剪除過時的記錄。

但是，當一個TON ADNL節點剛啟動時，它可能不知道任何其他節點，只能學到一個節點的IP地址和UDP端口，但不知其抽象地址。例如，如果一個輕型客戶端無法訪問之前緩存的任何節點和硬編碼到軟件中的任何節點，並必須要求用戶輸入節點的IP地址或DNS域名，以通過DNS進行解析。

在這種情況下，節點將發送數據包到該節點的特殊``zero channel''。這不需要知道收件人的公鑰（但消息仍應包含發件人的身份和簽名），所以消息是不加密地傳輸的。它通常只用於獲取接收者的身份（也許是特別為此目的創建的一次性身份），然後開始以更安全的方式通信。

一旦至少知道一個節點，就可以通過更多的條目輕鬆填充``neighbor table''和``routing table''，從已知節點發送的特殊查詢的回答中學到它們。

不是所有節點都需要處理發送到zero channel的數據包，但用於啟動輕型客戶端的節點應支持此功能。

\nxsubpoint \embt(TCP-like stream protocol over ADNL.)  ADNL，作為基於256位抽象地址的不可靠（小尺寸）數據包協議，可以用作更複雜網路協議的基礎。例如，可以構建一個類似TCP的流協議，使用ADNL作為IP的抽象替代品。但是，TON Project的大多數組件不需要這樣的流協議。

\nxsubpoint\label{sp:RLDP} \embt(RLDP, or Reliable Large Datagram
Protocol over ADNL.)  一個建立在ADNL上的可靠的任意大小的數據包協議，稱為RLDP，用於代替類似TCP的協議。這種可靠的數據包協議可以用來，例如，向遠程主機發送RPC查詢並從它們那裡接收答案（參見~\ptref{sp:pure.net.serv}）。

\mysubsection{TON DHT: Kademlia-like Distributed Hash
  Table}\label{sect:kademlia}

{\em TON 分散式雜湊表 (DHT)\/} 在TON Project的網路部分中扮演了關鍵角色，用於定位網路中的其他節點。例如，一個想要提交交易到某個shardchain的客戶端可能想要找到該shardchain的validator或collator，或至少某個可以將客戶端的交易轉發到collator的節點。這可以通過在TON DHT中查找特定的key來完成。TON DHT的另一個重要應用是，它可以快速填充新節點的鄰居表格 (參見~\ptref{sp:net.startup})，只需查找隨機key，或新節點的地址。如果節點對其入站數據報使用代理和通道，則將通道標識符和其入口點（例如，IP地址和UDP端口）發布在TON DHT中；然後，所有希望發送數據報到該節點的節點首先將從DHT獲取此聯繫信息。

TON DHT屬於{\em Kademlia-like分散式雜湊表\/}家族~\cite{Kademlia}。

\nxsubpoint \embt(Keys of the TON DHT.)  TON DHT的{\em keys\/}僅僅是256位整數。在大多數情況下，它們作為一個TL-serialized對象的$\Sha$計算出來（參見~\ptref{sp:TL}），被稱為key的{\em preimage\/}或{\em key description}。在某些情況下，TON Network節點的抽象地址（參見~\ptref{sp:abs.addr}）也可以用作TON DHT的keys，因為它們也是256位，而且它們也是TL-serialized對象的hashes。例如，如果節點不害怕公開其IP地址，任何知道其抽象地址的人都可以通過在DHT中查找該地址作為key來找到它。

\nxsubpoint \embt(Values of the DHT.)  分配給這些256-bit keys的{\em values\/}本質上是有限長度的任意字節串。對應key的preimage決定了這樣的字節串的解釋；通常由查找key的節點和儲存key的節點都知道它。

\nxsubpoint \embt(Nodes of the DHT. Semi-permanent network
identities.)  TON DHT的key-value映射存放在DHT的{\em nodes\/}上——基本上是TON Network的所有成員。為此，TON Network的任何節點（除了某些非常輕的節點外），除了~\ptref{sp:abs.addr}中描述的任意數量的瞬態和永久抽象地址外，都至少有一個“半永久地址”，該地址將其識別為TON DHT的成員。這個{\em 半永久\/}或{\em DHT地址\/}不應該經常更改，否則其他節點將無法找到他們正在尋找的keys。如果節點不想揭露其“真實”身份，則生成一個僅用於參與DHT的單獨抽象地址。但是，這個抽象地址必須是公開的，因為它將與節點的IP地址和端口相關聯。

\nxsubpoint \embt(Kademlia distance.) 現在，我們既有256位的 keys 也有256位的 (半永久) 節點地址。我們引入所謂的 {\em XOR distance\/} 或 {\em Kademlia distance~$d_K$} 在256位序列集上，由以下公式給出
\begin{equation}
  d_K(x,y):=(x\oplus y)\quad\text{解釋為一個無符號的256位整數}
\end{equation}
其中 \(x\oplus y\) 表示兩個相同長度的位序列的位元對位元 eXclusive OR (XOR)。

Kademlia distance 在所有256位序列的集合 \(\st2^{256}\) 上引入了一個度量。特別地，我們有 \(d_K(x,y)=0\) 當且僅當 \(x=y\)， \(d_K(x,y)=d_K(y,x)\)，和 \(d_K(x,z)\leq d_K(x,y)+d_K(y,z)\)。另一個重要特性是，{\em 從~\(x\) 出發的任何給定距離只有一個點}： \(d_K(x,y)=d_K(x,y')\) 意味著 \(y=y'\)。

\nxsubpoint \embt(Kademlia-like DHTs and the TON DHT.) 如果一個擁有256位 keys 和 256位節點地址的分散式雜湊表 (DHT) 預期將 key \(K\) 的值保留在與 \(K\) 最接近的 \(s\) 個Kademlia節點上 (即，與他們的地址到 \(K\) 的Kademlia distance 最小的 \(s\) 個節點)，我們稱之為 {\em Kademlia-like DHT\/}。

這裡的 \(s\) 是一個小參數，比如說，\(s=7\)，用於提高DHT的可靠性（如果我們只在一個節點上保留 key，即與 \(K\) 最接近的節點，那麼如果該節點離線，該 key 的值將會丟失）。

根據此定義，TON DHT 是一個Kademlia-like DHT。它是在~\ptref{sect:ANL}中描述的ADNL協議上實現的。

\nxsubpoint \embt(Kademlia routing table.) 任何參與Kademlia-like DHT的節點通常都會維護一個 {\em Kademlia routing table}。對於TON DHT，它由 \(n=256\) 個buckets組成，編號從 \(0\) 到 \(n-1\)。第 \(i\) 個bucket將包含一些已知節點的資訊（一定數量 \(t\) 的``最好的''節點，和可能一些額外的候選節點），這些節點的Kademlia distance從 \(2^i\) 到 \(2^{i+1}-1\) 與節點地址 \(a\) 之間。\footnote{如果一個bucket中有足夠多的節點，它可以進一步細分為，比如說，八個子bucket，這取決於Kademlia distance的前四位。這將加快DHT查找的速度。} 這些資訊包括他們的(半永久)地址、IP地址和UDP端口，以及一些可用性資訊，如最後一次ping的時間和延遲。

當一個Kademlia節點由於某個查詢得知其他Kademlia節點時，它將其包含到其路由表的適當bucket中，首先作為候選節點。然後，如果該bucket中的一些``最好的''節點失效（例如，長時間不回應ping查詢），它們可以被一些候選節點替換。通過這種方式，Kademlia routing table保持填充。

Kademlia routing table中的新節點也被包含在~\ptref{sp:net.startup}中描述的ADNL鄰居表中。如果Kademlia routing table的一個bucket中的``最好的''節點經常被使用，可以建立一個在~\ptref{sp:net.channels}中描述的channel，以促進datagrams的加密。

TON DHT的一個特殊特性是，它試圖選擇往返延遲最小的節點作為Kademlia routing table的buckets的``最好的''節點。

\nxsubpoint (Kademlia網路查詢。) 一個Kademlia節點通常支持以下網路查詢：
\begin{itemize}
\item $\Ping$ -- 檢查節點的可用性。
\item $\Store(key,value)$ -- 要求節點保存$value$作為$key$的值。對於TON DHT，$\Store$查詢稍微複雜一些 (參考~\ptref{sp:DHT.store})。
\item $\FindNode(key,l)$ -- 要求節點返回$l$ Kademlia最接近的已知節點（從其Kademlia路由表中）到$key$。
\item $\FindValue(key,l)$ -- 如上所述，但如果節點知道對應於key $key$的值，則直接返回該值。
\end{itemize}

當任何節點想要查找key $K$的值時，它首先創建一組$s'$節點（對於某個小的$s'$值，例如，$s'=5$），這些節點相對於所有已知節點的Kademlia距離最接近$K$（即，它們是從Kademlia路由表中取出的）。然後，$\FindValue$查詢發送給它們中的每一個，並在其答案中提到的節點包含在$S$中。然後，$S$中最接近$K$的$s'$節點也發送了$\FindValue$查詢（如果以前沒有這麼做），並且該過程繼續，直到找到該值或$S$停止增長。這是一種尋找相對於Kademlia距離最接近$K$的節點的``光束搜索''。

如果要設置某個key $K$的值，則為$s'\geq s$運行相同的過程，使用$\FindNode$查詢而不是$\FindValue$，以找到最接近$K$的$s$節點。之後，$\Store$查詢發送給它們所有人。

在Kademlia類似的DHT的實現中還有一些不太重要的細節（例如，任何節點應該每小時查找一次最接近自己的$s$節點，並通過$\Store$查詢重新發布所有儲存的key給它們）。我們暫時忽略它們。

\nxsubpoint \embt(Booting a Kademlia node.) 當一個Kademlia節點上線時，它首先通過查找自己的地址來填充其Kademlia路由表。在此過程中，它識別出最接近自己的$s$節點。它可以從它們那裡下載所有已知的$(key,value)$對，以填充其DHT的部分。

\nxsubpoint\label{sp:DHT.store} \embt(Storing values in TON DHT.)
在TON DHT中儲存值與一般的Kademlia-like DHT略有不同。當某人希望儲存一個值時，她不僅必須將鍵$K$本身提供給$\Store$查詢，還必須提供其{\em preimage\/}---也就是說，一個TL序列化的字符串（在開頭有幾個預定義的TL-constructors）包含鍵的``描述''。此鍵描述稍後由節點保存，並與鍵和值一起保存。

鍵描述描述了儲存的對象的``類型''、其``所有者''以及在未來更新時的``更新規則''。所有者通常由包含在鍵描述中的公鑰識別。如果包含它，通常只接受由相應的私鑰簽名的更新。儲存的對象的``類型''通常只是一個字節字符串。但是，在某些情況下，它可以更為複雜---例如，輸入隧道描述（參考~\ptref{sp:tunnels}），或節點地址的集合。

``更新規則''也可能不同。在某些情況下，它們僅允許使用新值替換舊值，前提是新值由所有者簽名（簽名必須作為值的一部分保存，以便稍後由其他節點在獲得此鍵的值後進行檢查）。在其他情況下，舊值以某種方式影響新值。例如，它可以包含一個序列號，並且僅當新的序列號更大時才覆蓋舊值（以防止重放攻擊）。

\nxsubpoint\label{sp:distr.torr.tr} \embt(Distributed ``torrent trackers'' and ``network interest groups'' in TON DHT.)
另一個有趣的情況是當值包含一個節點列表---也許是它們的IP地址和端口，或者只是它們的抽象地址---和``更新規則''包括在此列表中包括請求者，只要她可以確認她的身份。

這種機制可以用於創建一個分佈式的``torrent tracker''，在其中所有對某個``torrent''（即，某個文件）感興趣的節點可以找到對同一個torrent感興趣或已經擁有副本的其他節點。

{\em TON Storage\/} (參考~\ptref{sp:ex.ton.storage})使用此技術來找到擁有所需文件副本的節點（例如，shardchain的狀態快照或舊的區塊）。然而，其更重要的用途是創建``overlay multicast subnetworks''和``network interest groups''（參考~\ptref{sect:overlay}）。其想法是只有一些節點對特定shardchain的更新感興趣。如果shardchains的數量變得非常大，則找到對相同shard感興趣的節點可能會變得很複雜。這個``distributed torrent tracker''提供了一種方便的方法來找到這些節點。另一個選項是從validator那裡請求它們，但這不會是一個可擴展的方法，validator可能選擇不回應來自任意未知節點的這種查詢。

\nxsubpoint \embt(Fall-back keys.) 目前描述的大多數``key types''在其TL描述中都有一個額外的32位整數字段，通常等於零。但是，如果通過hash該描述獲得的鍵不能從TON DHT中檢索或更新，則會增加此字段中的值，並進行新的嘗試。這樣，通過創建許多靠近被攻擊鍵的抽象地址並控制相應的DHT節點，就不能``capture''和``censor''一個鍵（即，進行鍵保留攻擊）。

\nxsubpoint\label{sp:loc.serv} \embt(Locating services.) 一些位於TON Network中的服務，通過（基於TON ADNL的）較高級別的協議（在~\ptref{sect:ANL}中描述）提供，可能希望在某處公開其抽象地址，以便其客戶知道在哪裡找到它們。

但是，將服務的抽象地址發佈到TON Blockchain中可能不是最好的方法，因為可能需要經常更改抽象地址，並且可能有意義提供多個地址，出於可靠性或負載均衡的目的。

另一種方法是將公鑰發佈到TON Blockchain中，並使用一個特殊的DHT鍵，在TL描述字符串（參考~\ptref{sp:TL}）中指示該公鑰為其``owner''，以發佈服務的抽象地址的最新列表。這是TON Services利用的方法之一。


\nxsubpoint \embt(Locating owners of TON blockchain accounts.) 在大多數情況下，TON區塊鏈賬戶的所有者不希望與抽象網路地址，特別是IP地址相關聯，因為這可能侵犯他們的隱私。然而，在某些情況下，TON區塊鏈賬戶的所有者可能想要發佈她可以被聯繫到的一個或多個抽象地址。

一個典型的情況是TON Payments的“lightning network”中的節點（參考~\ptref{sect:lightning}），這是即時加密貨幣轉賬的平台。一個公開的TON Payments節點可能不僅想與其他節點建立支付通道，還想發佈一個抽象網路地址，稍後可以用該地址聯繫它，以沿著已建立的通道進行支付。

一種選擇是在創建支付通道的智能合約中包含一個抽象網路地址。更靈活的選擇是在智能合約中包括一個公鑰，然後像在~\ptref{sp:loc.serv}中解釋的那樣使用DHT。

最自然的方法是使用控制TON區塊鏈中賬戶的同一私鑰，來簽名和發佈關於與該賬戶相關的抽象地址的TON DHT中的更新。這幾乎與在~\ptref{sp:loc.serv}中描述的方式相同;但是，所使用的DHT鍵將需要一個特殊的鍵描述，只包含$\accountid$本身，等於“賬戶描述”的$\Sha$，其中包含賬戶的公鑰。該值中包含的簽名也將包含賬戶描述。

通過這種方式，提供了一種定位某些TON區塊鏈賬戶所有者的抽象網路地址的機制。

\nxsubpoint\label{sp:loc.abs.addr} \embt(Locating abstract addresses.) 請注意，儘管TON DHT是在TON ADNL上實現的，但TON ADNL也用它來實現幾個目的。

其中最重要的是從其256位抽象地址開始定位節點或其聯繫數據。這是必要的，因為TON ADNL應該能夠向任意256位抽象地址發送數據包，即使沒有提供任何其他信息。

為此，只需將256位抽象地址作為DHT中的鍵查找。找到使用該地址的節點（即，使用此地址作為公共半永久DHT地址），在這種情況下，可以獲知其IP地址和端口;或者，可以獲取一個由正確的私鑰簽名的問題鍵值的輸入隧道描述，在這種情況下，將使用此隧道描述將ADNL數據包發送到預期的接收者。

請注意，為了使抽象地址“公開”（可以從網路中的任何節點到達），其所有者必須使用它作為半永久DHT地址，或在考慮的抽象地址下的DHT鍵中發佈一個輸入隧道描述，使用其另一個公共抽象地址（例如，半永久地址）作為隧道的入口點。另一個選擇是簡單地發佈其IP地址和UDP端口。


\mysubsection{Overlay Networks 和 Multicasting
  Messages}\label{sect:overlay}

在像TON區塊鏈這樣的多區塊鏈系統中，即使是全節點
也通常只對獲取某些shardchains的更新（即新的區塊）感興趣。為此，必須在TON Network內部構建一個特殊的overlay（子）網路，基於在~\ptref{sect:ANL}中討論的ADNL協議，每個shardchain一個。

因此，需要建立任意的overlay子網路，對希望參與的任何節點開放。這些overlay網路中將運行基於ADNL的特殊gossip協議。特別是，這些gossip協議可用於在這樣的子網路內部傳播（廣播）任意數據。

\nxsubpoint \embt(Overlay networks.) 一個{\em overlay (sub)network\/}只是在某個更大的網路內部實現的（虛擬）網路。通常只有較大網路的一些節點參與overlay子網路，並且只有這些節點之間的一些物理或虛擬“鏈接”是overlay子網路的一部分。

這樣，如果將包含網路表示為圖（在像ADNL這樣的數據包網路的情況下可能是一個完整的圖，其中任何節點都可以輕鬆地與其他節點通信），則overlay子網路是此圖的{\em subgraph\/}。

在大多數情況下，使用構建於較大網路的網路協議之上的某些協議實現overlay網路。它可以使用與較大網路相同的地址，或使用自定義地址。

\nxsubpoint\label{sp:ton.overlays} \embt(Overlay networks in TON.) TON中的overlay網路基於在~\ptref{sect:ANL}中討論的ADNL協議構建;它們也使用256位ADNL抽象地址作為overlay網路中的地址。每個節點通常選擇其抽象地址中的一個，也作為其在overlay網路中的地址。

與ADNL相反，TON overlay網路通常不支持向任意其他節點發送數據包。相反，一些“半永久鏈接”在某些節點之間建立（被稱為考慮的overlay網路的“鄰居”），並且消息通常沿這些鏈接轉發（即，從一個節點到其鄰居之一）。通過這種方式，TON overlay網路是ADNL網路的（通常不完整的）子圖內。

TON overlay網路中的鄰居鏈接可以使用專用的點對點ADNL通道來實現（參考~\ptref{sp:net.channels}）。

overlay網路的每個節點都維護一個鄰居列表（關於overlay網路），包含它們的抽象地址（它們用於在overlay網路中識別它們）和一些鏈接數據（例如，用於與它們通信的ADNL通道）。


\nxsubpoint \embt(Private and public overlay networks.) 有些overlay網路是{\em public}，意味著任何節點都可以隨意加入。另一些是{\em private}，意味著只有某些節點可以被允許（例如，那些可以證明他們作為validator的身份的節點。）一些private overlay網路甚至可能對“一般公眾”未知。這些overlay網路的資訊只提供給某些受信任的節點；例如，它可以使用公鑰加密，並且只有擁有相應私鑰副本的節點才能解密此資訊。

\nxsubpoint \embt(Centrally controlled overlay networks.) 有些overlay網路是{\em centrally controlled}，由一個或幾個節點或某個眾所周知的公鑰的所有者控制。其他則是{\em decentralized}，意味著沒有特定節點負責它們。

\nxsubpoint \embt(Joining an overlay network.) 當一個節點想要加入一個overlay網路時，它首先必須學習其256位的{\em network identifier}，通常等於overlay網路的{\em description\/}的$\Sha$—一個TL-serialized物件（參考~\ptref{sp:TL}），這可能包含overlay網路的中央權威（即，其公鑰和可能的抽象地址\footnote{或者，抽象地址可能儲存在DHT中，如~\ptref{sp:loc.serv}所解釋的。}）一個與overlay網路的名稱相對應的字符串，如果這是與該shard相關的overlay網路，TON Blockchain shard的標識符，等等。

有時從網路標識符開始可以恢復overlay網路描述，只需在TON DHT中查找它即可。在其他情況下（例如，對於private overlay網路），必須與網路標識符一起獲得網路描述。

\nxsubpoint\label{sp:loc.1.mem} \embt(Locating one member of the
overlay network.) 在一個節點學到它想要加入的overlay網路的網路標識符和網路描述之後，它必須定位屬於該網路的至少一個節點。

這也適用於不想加入overlay網路，但只是想與其通信的節點；例如，可能有一個專用於為特定shardchain收集和傳播交易候選者的overlay網路，客戶端可能想連接到此網路的任何節點以建議交易。

用於定位overlay網路成員的方法在該網路的描述中定義。有時（尤其是對於private網路），必須已經知道一個成員節點才能加入。在其他情況下，某些節點的抽象地址包含在網路描述中。一種更靈活的方法是在網路描述中只指示負責網路的中央權威，然後抽象地址將通過某些DHT鍵的值提供，由該中央權威簽名。

最後，真正的decentralized public overlay網路可以使用描述在~\ptref{sp:distr.torr.tr}中的“分佈式torrent-tracker”機制，也使用TON DHT的幫助來實現。


\nxsubpoint\label{sp:loc.many.mem} \embt(Locating more members of the overlay network. Creating links.) 一旦找到overlay network的一個節點，可以向該節點發送一個特殊的查詢，要求提供其他成員的列表，例如，被查詢節點的鄰居或其隨機選擇。

這使得加入的成員能夠根據overlay network填充其“相鄰性”或“鄰居列表”，通過選擇一些新學到的網路節點並與它們建立連接（即，專用的ADNL點對點通道，如~\ptref{sp:ton.overlays}中所述）。之後，向所有鄰居發送特殊消息，表示新成員已準備好在overlay network中工作。鄰居在其鄰居列表中包含到新成員的連接。

\nxsubpoint\label{sp:rand.mem} \embt(Maintaining the neighbor list.) Overlay network節點必須不時更新其鄰居列表。一些鄰居，或至少是到它們的連接（通道），可能停止響應；在這種情況下，這些連接必須被標記為“暫停”，必須嘗試重新連接到這些鄰居，如果這些嘗試失敗，則必須銷毀這些連接。

另一方面，每個節點有時從隨機選擇的鄰居處請求其鄰居列表（或其隨機選擇），並使用它部分地更新自己的鄰居列表，通過向其添加一些新發現的節點，並移除一些舊的節點，無論是隨機的還是依賴於其響應時間和數據包丟失統計數據。

\nxsubpoint \embt(The overlay network is a random subgraph.) 這樣，overlay network在ADNL網路內部成為一個隨機子圖。如果每個頂點的度至少為三（即，如果每個節點至少連接到三個鄰居），則這個隨機圖以接近一的概率被知道是{\em connected\/}。更確切地說，具有$n$頂點的隨機圖是{\em dis\/}connected的概率是指數級小的，如果例如$n\geq20$，這個概率可以完全忽略。（當然，如果全域網路分區時，這不適用，當分區的不同側面的節點沒有機會了解彼此時。）另一方面，如果$n$小於20，只需要求每個頂點至少有，比如，至少十個鄰居。

\nxsubpoint\label{sp:ov.opt.low.lat} \embt(TON overlay networks are optimized for lower latency.) TON overlay網路按照以下方法優化前一方法生成的“隨機”網路圖。每個節點都嘗試保留至少三個最小往返時間的鄰居，並很少更改這個“快速鄰居”列表。同時，它還具有至少其他三個完全隨機選擇的“慢鄰居”，以使overlay network圖始終包含一個隨機子圖。這是為了保持連接性並防止overlay network分裂為幾個未連接的區域子網路。還選擇並保留至少三個“中間鄰居”，這些鄰居具有由某個常數（實際上，快鄰居和慢鄰居的往返時間的函數）界定的中間往返時間。

這樣，overlay network的圖形仍然保持足夠的隨機性以保持連接，但是經過優化以實現較低的延遲和更高的吞吐量。

\nxsubpoint \embt(Gossip protocols in an overlay network.) 在overlay network中，經常用來執行所謂的 {\em gossip protocols}，它在讓每個節點只與其鄰居互動的同時達到某個全域目標。例如，有一些gossip protocols用於構建一個(不太大) overlay network的所有成員的大致列表，或者只用每個節點有限的記憶體計算(任意大) overlay network的成員數量的估計 (參考~\cite[4.4.3]{DistrSys} 或 \cite{Birman}了解詳情)。

\nxsubpoint \embt(Overlay network as a broadcast domain.) 在overlay network中運行的最重要的gossip protocol是 {\em broadcast protocol}，旨在傳播由網路的任何節點，或者其中一個指定的發送節點生成的廣播消息，給所有其他節點。

實際上有幾種廣播協議，為不同的使用情境進行了優化。其中最簡單的一種接收新的廣播消息，並將其轉發給尚未自己發送該消息副本的所有鄰居。

\nxsubpoint \embt(More sophisticated broadcast protocols.) 某些應用程序可能需要更為複雜的廣播協議。例如，對於廣播大尺寸的消息，將新收到的消息的hash（或新消息的hash集合）而不是消息本身發送給鄰居是有意義的。在學習到先前未見過的消息hash後，鄰居可以請求消息本身，例如，使用在~\ptref{sp:RLDP}中討論的可靠的大數據包協議(RLDP)進行傳輸。這樣，新消息只會從一個鄰居下載。

\nxsubpoint \embt(Checking the connectivity of an overlay network.) 如果overlay network中有一個已知的節點（例如，overlay network的“擁有者”或“創建者”），則可以檢查overlay network的連接性。然後，該節點不時地廣播包含當前時間、序列號和其簽名的短消息。任何其他節點如果在不久之前收到過這樣的廣播，就可以確定它仍然連接到overlay network。此協議可以擴展到多個已知節點的情況；例如，它們都會發送這樣的廣播，所有其他節點都將期望從超過一半的已知節點那裡接收到廣播。

在用於傳播特定shardchain的新區塊（或僅新區塊頭）的overlay network的情況下，一個節點檢查連接性的好方法是追踪到目前為止收到的最新區塊。因為一個區塊通常每五秒生成一次，如果超過，比如，三十秒都沒有收到新的區塊，那麼節點可能已經從overlay network中斷開了。

\nxsubpoint\label{sp:streaming.multicast} \embt(Streaming broadcast protocol.) 終於，TON overlay network中有一個{\em streaming broadcast protocol\/}，例如，用於在某些shardchain的validator之間傳播區塊候選者（“shardchain task group”），當然，他們為此目的創建了一個私有的overlay network。相同的協議可以用來將新的shardchain區塊傳播給該shardchain的所有完整節點。

此協議已在~\ptref{sp:sh.blk.cand.prop}中描述過：新的（大）廣播消息被分成，比如說，$N$個一千字節的片段；這些片段的序列通過像Reed-Solomon或一個噴泉碼（例如，RaptorQ碼\cite{RaptorQ} \cite{Raptor}）這樣的消除碼擴展到$M\geq N$的片段，並且這些$M$片段按升序的chunk number順序流向所有鄰居。參與的節點收集這些片段，直到它們可以恢復原始的大消息（為此，必須成功接收至少$N$的片段），然後指示其鄰居停止發送流的新片段，因為現在這些節點可以擁有原始消息的副本自己生成後續的片段。這些節點繼續生成流的後續片段並將它們發送給它們的鄰居，除非鄰居反過來指示不再需要這樣做。

這樣，節點在進一步傳播它之前不需要完整地下載一個大消息。這最大限度地減少了廣播延遲，尤其是當與~\ptref{sp:ov.opt.low.lat}中描述的優化相結合時。

\nxsubpoint \embt(Constructing new overlay networks based on existing ones.) 有時，人們不想從頭開始構建一個overlay network。相反，一個或幾個先前存在的overlay network是已知的，並且新的overlay network的成員資格預計會與這些overlay network的組合成員資格重疊。

一個重要的例子出現在TON shardchain被分成兩個，或兩個同級的shardchains合併為一（參見~\ptref{sect:split.merge}）。在第一種情況下，必須為每一個新的shardchain構建用於向完整節點傳播新區塊的overlay networks；但是，可以預期這些新的overlay network中的每一個都包含在原始shardchain的區塊傳播網路中（並包含大約一半的成員）。在第二種情況下，合併shardchain的新區塊的傳播的overlay network將大致由與正在合併的兩個同級shardchains相關的兩個overlay network的成員組成。

在這些情況下，新的overlay network的描述可能包含對與一系列相關的現有overlay network的明確或隱含的參考。希望加入新的overlay network的節點可以檢查它是否已經是這些現有網路中的一個的成員，並詢問這些網路中的鄰居是否也對新網路感興趣。在得到肯定答案的情況下，可以建立到這些鄰居的新的點對點通道，並且它們可以被包括在新的overlay network的鄰居列表中。

這種機制並不完全取代在~\ptref{sp:loc.1.mem}和\ptref{sp:loc.many.mem}中描述的一般機制；相反，兩者都是並行運行的，並且用於填充鄰居列表。這是為了防止新的overlay network意外地分裂成幾個未連接的子網路。

\nxsubpoint\label{sp:net.within.net} \embt(Overlay networks within overlay networks.) 另一個有趣的案例出現在{\em TON Payments}的實現中（用於即時off-chain價值轉移的``lightning network''；參見~\ptref{sect:lightning}）。在這種情況下，首先構建包含所有``lightning network''的轉發節點的overlay network。但是，這些節點中的一些在區塊鏈中建立了支付通道；除了通過在~\ptref{sp:loc.1.mem}、\ptref{sp:loc.many.mem} 和~\ptref{sp:rand.mem}中描述的一般overlay network算法選擇的任何``隨機''鄰居外，它們在此overlay network中必須始終是鄰居。這些與建立支付通道的鄰居的``永久鏈接''用於運行特定的lightning network協議，從而在包含的（幾乎始終連接的）overlay network內部有效地創建了一個overlay子網路（如果事情出錯，則不一定連接）。


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%                  SERVICES
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\mysection{TON 服務與應用程式}\label{sect:services}

我們已經詳細討論了 TON 區塊鏈和 TON 網路技術。現在我們將解釋它們如何可以組合起來創建各種服務和應用程式，並討論 TON 專案本身將提供的一些服務，無論是從一開始還是在稍後的時間。

\mysubsection{TON 服務實施策略}%
\label{sect:ton.service.impl}

我們首先討論如何在 TON 生態系統內實施不同的區塊鏈和網路相關應用程式和服務。首先，一個簡單的分類是必要的：

\nxsubpoint \embt(Applications and services.) 我們將``應用程式''和``服務''這兩個詞互換使用。但是，其中有一個微妙且有點模糊的區別：一個 {\em 應用程式\/} 通常直接向人類用戶提供一些服務，而一個 {\em 服務\/} 通常被其他應用程式和服務所利用。例如，TON Storage 是一個服務，因為它是代表其他應用程式和服務保存文件的，即使人類用戶也可能直接使用它。一個假設的``在區塊鏈中的Facebook'' (參見~\ptref{sp:blockchain.facebook}) 或 Telegram 訊息傳遞應用，如果通過 TON 網路提供 (即，作為一個``ton-service''實施；參見~\ptref{sp:telegram.ton.serv})，則更像是一個 {\em 應用程式}，即使一些``機器人''可能在沒有人工干預的情況下自動訪問它。

\nxsubpoint\label{sp:on.off.chain} \embt(Location of the application: on-chain, off-chain or mixed.) 為 TON 生態系設計的服務或應用程式需要將其數據保存並在某處處理該數據。這導致了以下應用程式（和服務）的分類：
\begin{itemize}
\item {\em On-chain\/} 應用程式 (參見~\ptref{sp:pure.blockchain})：所有數據和處理都在 TON 區塊鏈中。
\item {\em Off-chain\/} 應用程式 (參見~\ptref{sp:pure.net.serv})：所有數據和處理都在 TON 區塊鏈之外，在通過 TON 網路提供的伺服器上。
\item {\em Mixed\/} 應用程式 (參見~\ptref{sp:mixed.serv})：部分，但不是所有，數據和處理都在 TON 區塊鏈中；其餘的都在通過 TON 網路提供的off-chain伺服器上。
\end{itemize}

\nxsubpoint \embt(Centralization: centralized and decentralized, or distributed, applications.) 另一個分類標準是應用程式（或服務）是否依賴於集中的伺服器集群，或者真的是``分佈式'' (參見~\ptref{sp:fog})。所有on-chain應用程式都自動地是去中心化和分佈式的。Off-chain和混合應用程式可能呈現出不同程度的集中化。

\medbreak
現在讓我們更詳細地考慮上述可能性。

\nxsubpoint\label{sp:pure.blockchain} \embt(Pure ``on-chain'' applications: distributed applications, or ``dapps'', residing in the blockchain.) 其中一種可能的方法，如在~\ptref{sp:on.off.chain}中提到的，是將一個「分散式應用程式」（通常縮寫為「dapp」）完全部署在TON區塊鏈中，作為一個智能合約或一組智能合約。所有數據都將作為這些智能合約的永久狀態部分保存，並且所有與該專案的交互都將通過發送到或從這些智能合約接收的(TON區塊鏈)消息來完成。

我們已經在~\ptref{sp:blockchain.facebook}中討論過這種方法有其缺點和限制。它也有其優點：這樣的分散式應用程式不需要伺服器來運行或儲存其數據（它運行在「區塊鏈中」---即在validator的硬體上），並享有區塊鏈極高的(拜占庭)可靠性和可訪問性。這種分散式應用的開發者不需要購買或租用任何硬體；她需要做的只是開發一些軟體（即智能合約的程式碼）。之後，她將有效地從validator那裡租用計算能力，並用Toncoin支付，要麼由她自己支付，要麼由她的用戶承擔。

\nxsubpoint\label{sp:pure.net.serv} \embt(Pure network services: ``ton-sites'' and ``ton-services''.) 另一個極端選擇是將服務部署在一些伺服器上，並通過在~\ptref{sect:ANL}中描述的ADNL協議使其供用戶使用，也許還有一些更高級的協議，如在~\ptref{sp:RLDP}中討論的RLDP，該協議可以用於以任何自訂格式向服務發送RPC查詢並獲得這些查詢的答案。這樣，該服務將完全在鏈外，並將駐留在TON網路中，幾乎不使用TON區塊鏈。

TON區塊鏈可能只用於查找服務的抽象地址或地址，如在~\ptref{sp:loc.serv}中概述的，也許還可以利用像TON DNS這樣的服務（參見~\ptref{sp:ton.dns}）來幫助將類似域的人類可讀字符串翻譯成抽象地址。

在ADNL網路（即TON網路）類似於Invisible Internet Project（$I^2P$）的程度上，這樣的（幾乎）純網路服務類似於所謂的「eep-services」（即，有一個$I^2P$-地址作為他們的入口點的服務，並通過$I^2P$網路提供給客戶）。我們會說，駐留在TON網路中的這些純網路服務是「ton-services」。

「eep-service」可以實現HTTP作為其客戶端-伺服器協議；在TON網路上下文中，「ton-service」可能只是使用RLDP（參見~\ptref{sp:RLDP}）數據報來傳輸HTTP查詢和響應。如果它使用TON DNS允許其抽象地址被一個人類可讀的域名查找，那麼與網站的類比就幾乎完美了。甚至可以寫一個專門的瀏覽器，或一個在用戶的機器上本地運行的特殊代理（「ton-proxy」），該代理接受來自用戶使用的普通網路瀏覽器的任意HTTP查詢（一旦代理的本地IP地址和TCP端口輸入到瀏覽器的配置中），並將這些查詢通過TON網路轉發到服務的抽象地址。然後用戶將擁有類似於世界寬網（WWW）的瀏覽體驗。

在$I^2P$生態系中，這樣的「eep-services」被稱為「eep-sites」。在TON生態系中也可以輕鬆創建「ton-sites」。這在某種程度上得到了TON DNS這類服務的幫助，它利用TON區塊鏈和TON DHT將(TON)域名翻譯成抽象地址。

\nxsubpoint\label{sp:telegram.ton.serv} \embt(Telegram Messenger as a ton-service; MTProto over RLDP.) 我們想順便提到MTProto協議\footnote{\url{https://core.telegram.org/mtproto}}，Telegram Messenger\footnote{\url{https://telegram.org/}}用於客戶端-伺服器交互，可以輕鬆嵌入到在\ptref{sp:RLDP}中討論的RLDP協議，從而實質上將Telegram轉化為ton-service。由於TON Proxy技術可以為ton-site或ton-service的終端用戶透明地開啟，並在RLDP和ADNL協議的下一級實施（參見\ptref{sp:tunnels}），這將使Telegram實質上不可封鎖。當然，其他消息和社交網路服務也可能從這項技術中受益。

\nxsubpoint\label{sp:mixed.serv} \embt(Mixed services: partly off-chain, partly on-chain.) 一些服務可能使用混合方法：大部分處理在鏈外，但也有一些鏈上的部分（例如，為了登記他們對用戶的義務，反之亦然）。通過這種方式，狀態的一部分仍然會被保存在TON Blockchain中（即，不可變的公共分類帳），並且服務或其用戶的任何不當行為可以由智能合約進行懲罰。

\nxsubpoint\label{sp:ex.ton.storage} \embt(Example: keeping files off-chain; TON Storage.) 這樣的服務的一個例子是由TON Storage提供的。在其最簡單的形式中，它允許用戶在鏈外儲存文件，只在鏈上保留要儲存的文件的雜湊值，可能還有一個智能合約，其中一些其他方同意在給定的時間段內為預先協商的費用保存該文件。實際上，文件可以被細分為一些小的大小（例如，1千字節），由擦除程式碼如Reed--Solomon或噴泉程式碼進行增強，可以為增強的塊序列構建一個Merkle tree雜湊值，並且這個Merkle tree雜湊值可能在智能合約中發布，而不是或與文件的通常雜湊一起。這有點讓人想起文件在torrent中的儲存方式。

儲存文件的更簡單形式完全是在鏈外：人們可能基本上為新文件創建一個「torrent」，並使用TON DHT作為此torrent的「分散式torrent追踪器」（參見\ptref{sp:distr.torr.tr}）。這對於受歡迎的文件可能實際上工作得很好。但是，您不會得到任何可用性保證。例如，一個假設的「區塊鏈Facebook」（參見\ptref{sp:blockchain.facebook}），它選擇在這種「torrents」中完全保留其用戶的個人資料照片，可能會冒著失去普通（不是特別受歡迎）的用戶的照片的風險，或者至少冒著在很長時間內無法顯示這些照片的風險。主要是在鏈外，但使用在鏈上的智能合約來強制執行儲存的文件的可用性的TON儲存技術，可能更適合這項任務。

\nxsubpoint\label{sp:fog} \embt(Decentralized mixed services, or ``fog services''.) 到目前為止，我們已經討論了{\em centralized\/}混合服務和應用程式。雖然它們的鏈上組件是以去中心化和分散的方式進行處理的，位於區塊鏈中，但它們的鏈下組件依賴於某些由服務提供商以常見的集中方式控制的伺服器。而不是使用一些專用伺服器，計算能力可能會從其中一家大公司提供的雲計算服務中租用。但是，這不會導致服務的鏈下組件的去中心化。

實現服務的鏈下組件的去中心化方法在於創建一個{\em 市場}，任何擁有所需硬體並願意出租其計算能力或磁碟空間的人都可以向需要它們的人提供服務。

例如，可能存在一個註冊表（也可以稱為「市場」或「交易所」），所有有興趣保存其他用戶文件的節點都在那裡發佈他們的聯繫信息，以及他們的可用儲存容量、可用性政策和價格。需要這些服務的人可能會在那裡查找它們，如果另一方同意，則在區塊鏈中創建智能合約並上傳文件進行鏈下儲存。這樣，像{\em TON Storage\/}這樣的服務就真正成為去中心化的，因為它不需要依賴任何集中的伺服器集群來儲存文件。

\nxsubpoint \embt(Example: ``fog computing'' platforms as decentralized mixed services.) 這種去中心化混合應用的另一個例子是當人們想執行一些特定計算（例如，3D渲染或訓練神經網路），通常需要特定且昂貴的硬體。然後擁有這種設備的人可能會通過類似的「交易所」提供他們的服務，需要這種服務的人則會租用它們，並通過智能合約註冊雙方的義務。這類似於``fog computing''平台，如Golem (\url{https://golem.network/}) 或 SONM (\url{https://sonm.io/})，所承諾提供的。

\nxsubpoint\label{sp:ex.ton.proxy} \embt(Example: TON Proxy is a fog service.) {\em TON Proxy\/} 提供了一個fog服務的另一個例子，希望提供其服務的節點（有償或無償）作為ADNL網路流量的隧道可能會註冊，需要它們的人可能會根據提供的價格、延遲和帶寬選擇其中一個節點。之後，人們可能會使用由{\em TON Payments\/}提供的支付通道來處理代理服務的微支付，例如，每傳輸128~KiB收取的付款。


\nxsubpoint \embt(Example: TON Payments is a fog service.) TON Payments平台(cf.~\ptref{sect:payments})也是這種去中心化混合應用的一個例子。

\mysubsection{連接使用者和服務提供者}\label{sect:reg.markt}

我們在~\ptref{sp:fog}中看到「fog services」(即混合去中心化服務)通常需要一些{\em 市場}、{\em 交易所\/}或{\em 註冊表}，在那裡需要特定服務的人可以遇到提供這些服務的人。

這些市場很可能作為鏈上、鏈下或混合服務本身被實現，無論是集中式還是分散式。

\nxsubpoint \embt(Example: connecting to TON Payments.) 例如，如果某人想使用TON Payments(cf.~\ptref{sect:payments})，第一步是找到至少一些現有的「lightning network」(cf.~\ptref{sect:lightning})的轉接節點，並與它們建立支付通道，如果它們願意的話。可以使用「包圍」的覆蓋網路找到一些節點，該網路應該包含所有的轉接lightning network節點(cf.~\ptref{sp:net.within.net})。但是，這些節點是否願意創建新的支付通道還不清楚。因此，需要一個註冊表，那些準備創建新連接的節點可以在其中發佈他們的聯繫信息（例如，他們的抽象地址）。

\nxsubpoint \embt(Example: uploading a file into TON Storage.) 同樣，如果某人想將文件上傳到TON Storage，她必須找到一些願意簽署智能合約的節點，將它們綁定到保留該文件的副本（或任何低於某個大小限制的文件）。因此，需要一個提供儲存文件服務的節點註冊表。

\nxsubpoint \embt(On-chain, mixed and off-chain registries.) 這種服務提供者註冊表可能完全在鏈上實現，借助一個智能合約來在其永久儲存中保留註冊表。但是，這將是相當緩慢和昂貴的。一種混合方法更為高效，其中相對較小且很少更改的鏈上註冊表只用於指出某些節點（通過它們的抽象地址，或者通過它們的公鑰，如在~\ptref{sp:loc.serv}中描述的那樣，可以用來查找實際的抽象地址），這些節點提供鏈下（集中式）的註冊服務。

最後，一種去中心化的、純鏈下的方法可能包括一個公共的覆蓋網路(cf.~\ptref{sect:overlay})，在那裡願意提供他們的服務的人，或者那些尋求購買某人服務的人，只需廣播由他們的私鑰簽名的優惠。如果要提供的服務非常簡單，甚至可能不需要廣播優惠：覆蓋網路本身的大致成員資格可以用作願意提供特定服務的人的「註冊表」。然後，需要此服務的客戶可以定位(cf.~\ptref{sp:loc.many.mem})並查詢此覆蓋網路的一些節點，然後查詢其鄰居，如果已知的節點不準備滿足其需求。


\nxsubpoint\label{sp:side.chain.reg} \embt(Registry or exchange in a
side-chain.)  另一種實現去中心化混合註冊表的方法是創建一個獨立的專用區塊鏈（「side-chain」），由其自己的一組自稱為validator的人維護，他們在on-chain智能合約中發佈他們的身份，並為所有感興趣的方提供網路訪問這個專用的區塊鏈，通過專用覆蓋網路收集交易候選人和廣播塊更新（cf.~\ptref{sect:overlay}）。然後，這個sidechain的任何完整節點都可以維護其自己的共享註冊表副本（本質上等於此side-chain的全域狀態），並處理與此註冊表相關的任意查詢。

\nxsubpoint \embt(Registry or exchange in a workchain.) 另一個選擇是在TON區塊鏈內創建一個專用的workchain，專門用於創建註冊表、市場和交易所。這可能比使用位於基本workchain中的智能合約更有效率和更便宜(cf.~\ptref{sp:basic.workchain})。但是，這仍然比在side-chains中維護註冊表更昂貴(cf.~\ptref{sp:side.chain.reg}）。

\mysubsection{訪問TON服務}

我們已經在~\ptref{sect:ton.service.impl}中討論了創建居於TON生態系中的新服務和應用程序的不同方法。現在，我們討論如何訪問這些服務，以及TON將提供的一些「輔助服務」，包括{\em TON DNS\/}和{\em TON Storage}。

\nxsubpoint\label{sp:ton.dns} \embt(TON DNS: a mostly on-chain
hierarchical domain name service.) {\em TON DNS\/}是一個預定義的服務，它使用一系列的智能合約來從人類可讀的域名映射到ADNL網路節點和TON區塊鏈賬戶和智能合約的（256位）地址。

雖然原則上任何人都可以使用TON區塊鏈實現這樣的服務，但擁有這樣一個預定義的服務，並具有一個眾所周知的界面，當一個應用程序或服務希望將人類可讀的標識符轉換為地址時，將其用作默認選擇是很有用的。

\nxsubpoint \embt(TON DNS use cases.) 例如，希望將一些加密貨幣轉移給另一個用戶或商家的用戶可能更喜歡記住該用戶或商家賬戶的TON DNS域名，而不是手頭保留他們的256位賬戶識別碼並將它們複製粘貼到他們的輕錢包客戶端的收件人字段中。

同樣地，TON DNS可以用來查找智能合約的賬戶識別碼或ton-services和ton-sites的入口點（cf.~\ptref{sp:pure.net.serv}），使得一個專用客戶端（「ton-browser」）或一個與專用ton-proxy擴展或獨立應用程序耦合的常見互聯網瀏覽器，能夠為用戶提供一個類似WWW的瀏覽體驗。

\nxsubpoint \embt(TON DNS smart contracts.)  TON DNS是通過一系列特殊的(DNS)智能合約來實現的。每一個DNS智能合約都負責註冊某固定域的子域名。``根'' DNS智能合約，即TON DNS系統的一級域名所在的位置，位於masterchain中。所有希望直接訪問TON DNS數據庫的軟件都必須將其帳戶標識符硬編碼。

任何DNS智能合約都包含一個hashmap，將可變長度的以null結尾的UTF-8字符串映射到它們的``值''。這個hashmap是作為一個二進制的Patricia樹來實現的，與在~\ptref{sp:patricia}中描述的類似，但支持可變長度的bitstrings作為鍵。

\nxsubpoint \embt(Values of the DNS hashmap, or TON DNS records.)  至於值，它們是由TL-scheme描述的``TON DNS記錄'' (cf.~\ptref{sp:TL})。它們包括一個``魔數''，選擇其中的一個支持的選項，然後是一個帳戶標識符、或一個智能合約標識符、或一個抽象網路地址(cf.~\ptref{sect:ANL})，或一個用於查找服務的抽象地址的公鑰 (cf.~\ptref{sp:loc.serv})，或一個覆蓋網路的描述，等等。一個重要的情況是另一個DNS智能合約：在這種情況下，該智能合約用於解析其域的子域名。通過這種方式，可以為不同的域創建單獨的註冊表，由這些域的所有者控制。

這些記錄還可以包含一個到期時間、一個緩存時間（通常非常大，因為在區塊鏈中太經常更新值是昂貴的），並且在大多數情況下引用所問子域名的所有者。所有者有權更改此記錄（尤其是所有者字段，從而將域名轉移給其他人的控制），並對其進行延長。

\nxsubpoint \embt(Registering new subdomains of existing domains.)  為了註冊一個現有域的新子域，只需向該域的註冊者，即智能合約，發送一條消息，該消息包含要註冊的子域名（即鍵）、一個預定義格式之一的值、所有者的身份、一個到期日期，以及由該域的所有者確定的某個加密貨幣金額。

子域名是按照``先到先得''的原則註冊的。

\nxsubpoint\label{sp:dns.get} \embt(Retrieving data from a DNS smart
contract.)  原則上，對於包含DNS智能合約的masterchain或shardchain的任何完整節點，只要知道智能合約的持久儲存中hashmap的結構和位置，就可以查找該智能合約數據庫中的任何子域。

然而，這種方法只適用於某些DNS智能合約。如果使用的是非標準的DNS智能合約，它將徹底失效。

相反，我們使用基於{\em general smart contract
  interfaces\/}和{\em get methods\/}(cf.~\ptref{sp:get.methods})的方法。任何DNS智能合約都必須定義一個帶有``已知簽名''的``get method''，用於查找一個鍵。由於這種方法也適用於其他智能合約，尤其是那些提供on-chain和混合服務的合約，我們在~\ptref{sp:get.methods}中詳細解釋了它。

\nxsubpoint \embt(Translating a TON DNS domain.)  一旦任何完整節點，無論是獨立操作還是代表某個輕客戶端，都可以在任何DNS智能合約的數據庫中查找條目，就可以從已知的和固定的根DNS智能合約(帳戶)標識符遞歸地轉譯任意的TON DNS域名。

例如，如果想要轉譯\texttt{A.B.C}，可以在根域數據庫中查找鍵\texttt{.C}、\texttt{.B.C}和\texttt{A.B.C}。如果第一個鍵沒有找到，但第二個鍵找到了，且它的值是另一個DNS智能合約的引用，那麼就在該智能合約的數據庫中查找\texttt{A}，並檢索最終值。

\nxsubpoint \embt(Translating TON DNS domains for light nodes.)  這樣，對於masterchain的完整節點---以及參與域查找過程的所有shardchains---都可以在不需要外部幫助的情況下將任何域名轉譯為其當前值。輕節點可能會要求一個完整節點代替它執行這一操作，並返回值以及一個Merkle證明(cf.~\ptref{sp:merkle.query.resp})。這個Merkle證明使得輕節點可以驗證答案是正確的，因此這樣的TON DNS響應不能被惡意攔截器``偽造''，這與通常的DNS協議形成了鮮明的對比。

因為不能期望任何節點都是對所有shardchains的完整節點，實際的TON DNS域轉譯將涉及這兩種策略的組合。

\nxsubpoint \embt(Dedicated ``TON DNS servers''.)  人們可以提供一個簡單的``TON DNS伺服器''，它會接收RPC ``DNS'' 查詢（例如，通過在~\ptref{sect:ANL}中描述的ADNL或RLDP協議），請求伺服器轉譯給定的域名，如果需要，通過將某些子查詢轉發到其他（完整）節點來處理這些查詢，並返回對原始查詢的答案，如果需要，還可以增加Merkle證明。

這樣的``DNS伺服器''可能會使用在~\ptref{sect:reg.markt}中描述的其中一種方法，向任何其他節點，特別是輕型客戶端提供他們的服務（免費或付費）。請注意，如果這些伺服器被認為是TON DNS服務的一部分，它們將有效地將其從分佈式on-chain服務轉化為分佈式混合服務（即``fog service''）。

這結束了我們對TON DNS服務的簡短概述，這是一個可擴展的on-chain註冊表，用於TON Blockchain和TON Network實體的人類可讀域名。

\nxsubpoint \embt(Accessing data kept in smart contracts.)  我們已經看到，有時需要訪問儲存在智能合約中的數據，而不改變其狀態。

如果知道智能合約實施的詳細信息，可以從智能合約的持久儲存中提取所有所需的信息，所有shardchain的完整節點都可以使用該智能合約。然而，這是一種相當不雅的做事方式，非常依賴於智能合約的實施。

\nxsubpoint\label{sp:get.methods} \embt(``Get methods'' of smart
contracts.)  一個更好的方法是在智能合約中定義一些{\em get methods\/}，即一些類型的入站消息，當交付時不會影響智能合約的狀態，但會生成一個或多個包含``結果''的輸出消息的get方法。這樣，只要知道它實現了具有已知簽名的get方法（即已知要發送的入站消息的格式以及作為結果接收的出站消息的格式），就可以從智能合約中獲取數據。

這種方法更加優雅，並符合面向對象編程（OOP）。然而，到目前為止，它有一個明顯的缺陷：必須實際將交易提交到區塊鏈（將get消息發送到智能合約），等待它被提交並由validator處理，從新塊中提取答案，並支付燃氣費（即在validator的硬件上執行get方法）。這是資源的浪費：get方法無論如何都不會改變智能合約的狀態，所以它們不需要在區塊鏈中執行。

\nxsubpoint\label{sp:tent.exec.get} \embt(Tentative execution of get
methods of smart contracts.)  我們已經提到
(cf.~\ptref{sp:ext.msg})任何完整節點都可以嘗試執行任何智能合約的任何方法（即，將任何消息交付給智能合約），從智能合約的給定狀態開始，而無需實際提交相應的交易。完整節點可以簡單地將正在考慮的智能合約的程式碼加載到TON VM中，從shardchain的全域狀態（shardchain的所有完整節點都知道）初始化其持久儲存，並使用入站消息作為其輸入參數執行智能合約程式碼。所創建的輸出消息將產生此計算的結果。

通過這種方式，任何完整節點都可以評估任意智能合約的任意get方法，只要它們的簽名（即入站和出站消息的格式）是已知的。該節點可以跟踪在此評估期間訪問的shardchain狀態的cell，並為可能要求完整節點這樣做的輕型節點創建Merkle證明，證明所執行的計算的有效性（cf.~\ptref{sp:merkle.query.resp}）。

\nxsubpoint \embt(Smart-contract interfaces in TL-schemes.)  回憶一下，由智能合約實現的方法（即它接受的輸入消息）基本上是一些TL序列化對象，這些對象可以由TL-scheme描述（cf.~\ptref{sp:TL}）。所得到的輸出消息也可以由相同的TL-scheme描述。通過這種方式，智能合約提供給其他帳戶和智能合約的接口可以通過TL-scheme進行正式化。

特別是，可以通過這樣一個正式化的智能合約接口描述智能合約支持的（一部分）get方法。

\nxsubpoint\label{sp:pub.int.smartc} \embt(Public interfaces of a
smart contract.)  注意，一個正式化的智能合約接口，無論是以TL-scheme的形式（表示為TL源文件；cf.~\ptref{sp:TL}）還是以序列化形式，都可以發布---例如，在區塊鏈中儲存的智能合約帳戶描述的特殊字段中，或者單獨發布，如果這個接口將被多次引用。在後一種情況下，支持的公共接口的hash可能會被合併到智能合約描述中，而不是接口描述本身。

這樣一個公共接口的例子是DNS智能合約的接口，它應該至少實現一個用於查找子域的標準get方法（cf.~\ptref{sp:dns.get}）。在DNS智能合約的標準公共接口中也可以包括用於註冊新子域的標準方法。

\nxsubpoint\label{sp:ui.smartc} \embt(User interface of a smart
contract.)  智能合約的公共介面存在還有其他好處。例如，當用戶請求查看一個智能合約時，一個錢包客戶端應用程序可以下載這樣的介面，並顯示智能合約支持的公共方法（即，可用的操作）列表，如果在正式介面中提供了一些人類可讀的評論，也許會顯示出來。在用戶選擇其中一種方法後，可以根據TL-scheme自動生成一個表單，在其中用戶將被提示選擇所需的所有字段和要附加到此請求的加密貨幣（例如，Toncoin）的所需金額。提交此表單將創建一個新的區塊鏈交易，其中包含剛剛組成的消息，從用戶的區塊鏈帳戶發送。

通過這種方式，只要這些智能合約已經發布了它們的介面，用戶將能夠通過填寫和提交某些表格以用戶友好的方式從錢包客戶端應用程序與任意智能合約進行互動。

\nxsubpoint\label{sp:ui.ton.serv} \embt(User interface of a
``ton-service''.)  事實證明，“ton-services”（即，居住在TON Network中並通過~\ptref{sect:network}的ADNL和RLDP協議接受查詢的服務；cf.~\ptref{sp:pure.net.serv}）也可能從擁有公共介面中獲益，由TL-schemes描述（cf.~\ptref{sp:TL}）。一個客戶端應用程序，例如一個輕型錢包或一個“ton-browser”，可能會提示用戶選擇其中一個方法，並使用由介面定義的參數填寫一個表單，這與剛剛在~\ptref{sp:ui.smartc}中討論的類似。唯一的區別是，結果的TL-serialized消息不作為區塊鏈中的交易提交；相反，它作為一個RPC查詢發送到“ton-service”的抽象地址，並根據正式介面（即，一個TL-scheme）解析和顯示此查詢的響應。

\nxsubpoint\label{sp:ui.ton.dns} \embt(Locating user interfaces via
TON DNS.)  包含ton-service或智能合約帳戶標識符的抽象地址的TON DNS記錄還可能包含描述該實體的公共（用戶）介面的可選字段，或幾個支持的介面。然後，客戶端應用程序（無論是錢包、ton-browser還是ton-proxy）將能夠下載介面並以統一的方式與相應的實體（無論是智能合約還是ton-service）進行互動。

\nxsubpoint \embt(Blurring the distinction between on-chain and off-chain
services.)  這樣，對於最終用戶，區塊鏈上、區塊鏈下和混合服務之間的區別變得模糊（cf.~\ptref{sp:on.off.chain}）：她只需將所需服務的域名輸入到她的ton-browser或錢包的地址線中，其餘的工作由客戶端應用程序無縫處理。

\nxsubpoint\label{sp:telegram.integr} \embt(A light wallet and TON
entity explorer can be built into Telegram Messenger clients.)  在此階段出現了一個有趣的機會。可以將實現上述功能的輕量錢包和TON實體瀏覽器嵌入到Telegram Messenger智能手機客戶端應用程序中，從而將技術帶給超過2億人。用戶可以通過在消息中包含TON URIs（參見~\ptref{sp:ton.uri}）來發送指向TON實體和資源的超連結；如果選擇了這些超連結，接收方的Telegram客戶端應用程序將在內部打開它，並開始與選定的實體互動。

\nxsubpoint \embt(``ton-sites'' as ton-services supporting an HTTP
interface.)  一個{\em ton-site\/}簡單地說就是一個支持HTTP介面的ton-service，也許還有其他一些介面。這種支持可以在相應的TON DNS記錄中宣布。

\nxsubpoint \embt(Hyperlinks.)  請注意，由ton-sites返回的HTML頁面可能包含{\em ton-hyperlinks} --- 也就是，通過特殊製作的URI方案（參見~\ptref{sp:ton.uri}）引用其他ton-sites、智能合約和帳戶的參考 --- 包含抽象網路地址、帳戶識別符或可讀的TON DNS域。然後，當用戶選擇它時，``ton-browser''可能會遵循這樣的超連結，檢測要使用的介面，並顯示一個用戶介面表單，如\ptref{sp:ui.smartc}和~\ptref{sp:ui.ton.serv}中所述。

\nxsubpoint\label{sp:ton.uri} \embt(Hyperlink URLs may specify some
parameters.)  超連結URL可能不僅包含所述服務的(TON) DNS域或抽象地址，還包含要調用的方法名稱以及部分或所有的參數。這種URI方案可能如下所示：
\begin{quote}
\texttt{ton://}\textit{<domain>}\texttt{/}\textit{<method>}\texttt{?}%
\textit{<field1>}\texttt{=}\textit{<value1>}\texttt{\&}%
\textit{<field2>}\texttt{=}\dots
\end{quote}
當用戶在ton-browser中選擇這樣的鏈接時，要么立即執行該操作（特別是如果它是匿名調用的智能合約的get方法），要么顯示一個部分填充的表格，由用戶明確確認和提交（對於支付表格可能需要這樣做）。

\nxsubpoint \embt(POST actions.)  ton-site可以將它返回的HTML頁面嵌入到一些常見的POST表格中，其中的POST操作通過適當的(TON) URLs引用ton-sites、ton-services或智能合約。在這種情況下，一旦用戶填寫並提交了該自定義表單，就會採取相應的操作，無論是立即還是在明確確認後。


\nxsubpoint\label{sp:ton.www} \embt(TON WWW.)  上述所有內容都將導致在TON Network中建立一整個相互參照的實體網路，終端用戶可以通過ton-browser訪問它，為用戶提供類似WWW的瀏覽體驗。對於終端用戶來說，這將最終使區塊鏈應用基本上與他們已經習慣的網站相似。

\nxsubpoint \embt(Advantages of TON WWW.)  這個包括on-chain和off-chain服務的``TON WWW''相比於其常規對應物具有一些優勢。例如，支付在系統中是固有集成的。用戶身份可以始終呈現給服務（通過自動生成的交易和生成的RPC請求上的簽名），或者可以隱藏。服務不需要檢查和重新檢查用戶憑證；這些憑證可以一勞永逸地在區塊鏈中發布。可以很容易地通過TON Proxy保留用戶網路匿名性，並且所有服務都將有效地無法被封鎖。由於ton-browsers可以與TON支付系統集成，所以也可能並且容易進行小額支付。

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%                  PAYMENTS
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\mysection{TON 支付}\label{sect:payments}

我們在這篇文章中將簡短討論的 TON 專案的最後一個組件是 {\em TON Payments}，這是用於 (微型) 支付通道和 "lightning network" 值轉移的平台。它可以使支付「即時」完成，無需將所有交易提交到區塊鏈，支付相關的交易費用（例如，消耗的 gas），並等待五秒鐘，直到包含所涉交易的區塊被確認。

這樣的即時支付的總體開銷非常小，所以可以用於微支付。例如，TON 文件儲存服務可能會向用戶收取每下載 128 KiB 數據的費用，或者付費的 TON Proxy 可能需要對每 128 KiB 的中繼流量支付微小的費用。

雖然 {\em TON Payments\/} 可能比 TON 專案的核心組件晚些時候發布，但需要從一開始就進行一些考慮。例如，用於執行 TON 區塊鏈智能合約的程式碼的 TON 虛擬機 (TON VM; cf.~\ptref{sp:tonvm})，必須支持與 Merkle 證明的一些特殊操作。如果這樣的支持在原始設計中不存在，那麼在後期加入可能會變得有問題(cf.~\ptref{sp:genome.change.never})。但是，我們會看到，TON VM 本身就支持「智能」支付通道(cf.~\ptref{sp:ton.smart.pc.supp})。

\mysubsection{支付通道}

我們首先討論點對點支付通道，以及它們如何在 TON 區塊鏈中實施。

\nxsubpoint \embt(The idea of a payment channel.) 假設有兩個參與者，$A$ 和 $B$，他們知道在未來他們需要彼此進行大量的支付。他們不是將每筆付款作為一筆交易提交到區塊鏈，而是創建一個共享的「money pool」（或者也許是一個只有兩個帳戶的小型私有銀行），並向其中投入一些資金：$A$ 投入 $a$ 個幣，$B$ 投入 $b$ 個幣。這是通過在區塊鏈中創建一個特殊的智能合約，並向其發送資金來實現的。

在創建「money pool」之前，雙方同意某個協議。他們將跟踪 pool 的{\em 狀態}，即他們在共享 pool 中的餘額。原始的狀態是 $(a,b)$，意味著 $a$ 個幣實際上屬於 $A$，$b$ 個幣屬於 $B$。然後，如果 $A$ 想支付 $d$ 個幣給 $B$，他們可以簡單地同意新的狀態是 $(a',b')=(a-d,b+d)$。之後，如果，例如，$B$ 想支付 $d'$ 個幣給 $A$，那麼狀態將變成 $(a'',b'')=(a'+d',b'-d')$，依此類推。

所有這些在 pool 內部的餘額更新都是完全離鏈的。當雙方決定從 pool 中提取他們應得的資金時，他們會根據 pool 的最終狀態這樣做。這是通過向智能合約發送一條特殊的消息來實現的，該消息包含經 $A$ 和 $B$ 雙方簽名同意的最終狀態 $(a^*,b^*)$。然後，智能合約向 $A$ 發送 $a^*$ 個幣，向 $B$ 發送 $b^*$ 個幣，並自毀。

這個智能合約，以及 $A$ 和 $B$ 用於更新 pool 狀態的網路協議，是一個簡單的 {\em 在 $A$ 和~$B$ 之間的支付通道}。根據在~\ptref{sp:on.off.chain}中描述的分類，它是一個 {\em 混合} 服務：它的部分狀態位於區塊鏈中（智能合約），但大部分的狀態更新是離鏈的（由網路協議完成）。如果一切順利，雙方將能夠互相支付他們想要的金額（唯一的限制是通道的「容量」沒有超出——也就是說，他們在支付通道中的餘額都保持非負），只需要在區塊鏈中提交兩筆交易：一筆用於打開（創建）支付通道（智能合約），另一筆用於關閉（銷毀）它。

\nxsubpoint \embt(Trustless payment channels.)  先前的例子有些不切實際，因為它假設兩個參與者都願意合作，且永遠不會為了某些優勢而作弊。例如，想像$A$選擇不簽署最終的餘額$(a',b')$，其中$a'<a$。這將使$B$陷入困境。

為了防止這種情況，人們通常試圖開發{\em trustless\/}支付通道協議，這不需要參與者互相信任，且對試圖作弊的任何一方進行處罰。

這通常是在簽名的幫助下達到的。支付通道智能合約知道$A$和$B$的公鑰，且在需要時可以檢查其簽名。支付通道協議要求參與者簽署中間狀態並互相發送簽名。然後，如果參與者之一作弊——例如，假裝支付通道的某個狀態從未存在——可以通過顯示該狀態的簽名來證明其不正當行為。支付通道智能合約充當“on-chain arbiter”，能夠處理兩個參與者關於彼此的投訴，並通過沒收有罪一方的所有資金並授予給另一方來懲罰有罪一方。

\nxsubpoint\label{sp:simple.sync.pc} \embt(Simple bidirectional synchronous trustless payment channel.)  考慮以下更為真實的例子：讓支付通道的狀態由三元組$(\delta_i,i,o_i)$描述，其中$i$是狀態的序列號（最初為零，然後當後續狀態出現時增加一），$\delta_i$是{\em channel imbalance\/}（意味著$A$和$B$分別擁有$a+\delta_i$和$b-\delta_i$的硬幣），且$o_i$是被允許生成下一個狀態的參與者（$A$或$B$）。每個狀態必須在進一步進展之前由$A$和$B$簽名。

現在，如果$A$想要在支付通道內部將$d$個硬幣轉移到$B$，且當前狀態為$S_i=(\delta_i,i,o_i)$，其中$o_i=A$，那麼它只需創建一個新狀態$S_{i+1}=(\delta_i-d,i+1,o_{i+1})$，簽名並將其及其簽名發送給$B$。然後，$B$通過簽名並發送其簽名的副本給$A$來確認。之後，雙方都有一個帶有他們兩者簽名的新狀態的副本，且可能會發生新的轉賬。

如果$A$在$o_i=B$的$S_i$狀態下想要將硬幣轉移到$B$，那麼它首先要求$B$提交具有相同不平衡$\delta_{i+1}=\delta_i$的後續狀態，但$o_{i+1}=A$。之後，$A$將能夠進行其轉賬。

當兩個參與者同意關閉支付通道時，他們都在他們認為是最後的狀態$S_k$上放置他們特殊的{\em final\/}簽名，並通過將最終狀態及兩個最終簽名發送給支付通道智能合約來調用{\em clean\/}或{\em two-sided finalization method\/}。

如果另一方不同意提供其最終簽名，或者僅僅是停止回應，則可以單方面關閉該通道。為此，希望這麼做的一方將調用 {\em unilateral finalization\/} 方法，將其對於最終狀態的版本、其最終簽名，以及另一方最近的簽名狀態，發送到智能合約。在此之後，智能合約不會立即根據接收到的最終狀態採取行動。相反，它會等待一段特定的時間（例如，一天），讓另一方呈現其對於最終狀態的版本。當另一方提交其版本並且與已提交版本相容時，智能合約會計算"真正的"最終狀態並相應地分配資金。如果另一方未能向智能合約呈現其對於最終狀態的版本，那麼資金將根據呈現的最終狀態的唯一副本重新分配。

如果兩方之一作弊，例如，將兩個不同的狀態簽名為最終的，或者簽署兩個不同的下一個狀態 $S_{i+1}$ 和 $S'_{i+1}$，或者簽署一個無效的新狀態 $S_{i+1}$（例如，與不平衡 $\delta_{i+1}<-a$ 或 $>b$），那麼另一方可以將此行為的證據提交給智能合約的第三種方法。有罪的一方將立即被處罰，並完全失去其在支付通道中的份額。

這個簡單的支付通道協議是 {\em fair\/}，意味著任何一方都可以總是獲得其應得的，無論另一方是否合作，並且如果試圖欺騙，很可能失去其承諾給支付通道的所有資金。

\nxsubpoint\label{sp:sync.pc.as.blockch} \embt(Synchronous payment channel as a simple virtual blockchain with two validators.) 上面的簡單同步支付通道的示例可以這樣重新描述。想像一下，狀態序列 $S_0$、$S_1$、...、$S_n$ 實際上是一個非常簡單區塊鏈的區塊序列。這個區塊鏈的每個區塊基本上只包含區塊鏈的當前狀態，也許還有對前一個區塊（即其hash）的引用。$A$ 和 $B$ 兩方都作為此區塊鏈的validator，所以每個區塊必須收集他們兩人的簽名。區塊鏈的狀態 $S_i$ 定義了下一個區塊的指定生產者 $o_i$，所以 $A$ 和 $B$ 在生產下一個區塊時沒有競爭。生產者 $A$ 只能創建將資金從 $A$ 轉移到 $B$ 的區塊（即減少不平衡：$\delta_{i+1}\leq\delta_i$），$B$ 則只能將資金從 $B$ 轉移到 $A$（即增加 $\delta$）。

如果兩個validator同意區塊鏈的最後一個區塊（和最終狀態），則可以通過收集兩方的特殊“最終”簽名並與最終區塊一起提交到通道智能合約進行處理和相應地重新分配資金來確定它。

如果validator簽署一個無效的區塊，或者創建一個分叉，或者簽署兩個不同的最終區塊，它可以通過將其不端行為的證據提交給智能合約，這相當於一個validator失去其股份。


\nxsubpoint\label{sp:async.pc} \embt(Asynchronous payment channel as a
virtual blockchain with two workchains.) 先前討論的同步支付通道在\ptref{sp:simple.sync.pc}中有某些缺點：在前一筆交易被對方確認之前，不能開始下一筆交易（支付通道內的資金轉移）。這可以通過將\ptref{sp:sync.pc.as.blockch}中討論的單一虛擬區塊鏈替換為兩個互動的虛擬工作鏈（或碎片鏈）來解決。

第一個工作鏈只包含$A$的交易，且其區塊只能由$A$生成；它的狀態是$S_i=(i,\phi_i,j,\psi_j)$，其中$i$是區塊序列號（即$A$到目前為止執行的交易或資金轉移的計數）、$\phi_i$是到目前為止從$A$轉移到$B$的總額、$j$是$A$知道的$B$的區塊鏈中最近有效區塊的序列號，而$\psi_j$是在其$j$次交易中從$B$轉移到$A$的金額。$B$放在其第$j$-th區塊上的簽名也應該是此狀態的一部分。這個工作鏈的前一個區塊和另一個工作鏈的$j$-th區塊的hash也可能被包括。$S_i$的有效性條件包括$\phi_i\geq 0$、若$i>0$則$\phi_i\geq\phi_{i-1}$、$\psi_j\geq0$、以及$-a\leq\psi_j-\phi_i\leq b$。

相似地，第二個工作鏈只包含$B$的交易，且其區塊只能由$B$生成；它的狀態是$T_j=(j,\psi_j,i,\phi_i)$，具有相似的有效性條件。

現在，如果$A$想要將一些錢轉移給$B$，它只需在其工作鏈中創建一個新區塊，簽名，然後發送給$B$，無需等待確認。

支付通道是通過$A$簽名（其版本的）其區塊鏈的最終狀態（帶有其特殊的「最終簽名」）、$B$簽名其區塊鏈的最終狀態，並將這兩個最終狀態呈現給支付通道智能合約的清潔結算方法來完成的。單方面的終結也是可能的，但在那種情況下，智能合約將必須等待另一方呈現其最終狀態的版本，至少要有一些寬限期。

\nxsubpoint \embt(Unidirectional payment channels.) 如果只有$A$需要向$B$支付（例如，$B$是服務提供者，$A$是其客戶），則可以創建一個單方向的支付通道。本質上，它只是在\ptref{sp:async.pc}中描述的第一個工作鏈，沒有第二個。反之，可以說在\ptref{sp:async.pc}中描述的異步支付通道由兩個單向支付通道或「半通道」組成，由相同的智能合約管理。

\nxsubpoint\label{sp:pc.promises} \embt(More sophisticated payment
channels. Promises.) 我們稍後將在\ptref{sp:ch.money.tr}看到，「閃電網路」（參見\ptref{sect:lightning}）允許通過多個支付通道的鏈進行即時資金轉帳，這需要涉及的支付通道具有更高的複雜度。

具體來說，我們希望能夠承諾「promises」，或者說「條件性資金轉移」：$A$同意發送$c$硬幣給$B$，但只有在滿足某個條件時$B$才會得到錢，例如，如果$B$可以提供某個字串$u$並滿足$\Hash(u)=v$，其中$v$的值是已知的。否則，$A$可以在一段時間後取回錢。

這樣的承諾可以輕鬆地在區塊鏈上通過一個簡單的智能合約來實現。但是，我們希望在支付通道中，即off-chain，能夠實現promises和其他類型的條件性資金轉移，因為它們大大簡化了存在於「閃電網路」中的支付通道鏈的資金轉移（參見\ptref{sp:ch.money.tr}）。

在\ptref{sp:sync.pc.as.blockch}和\ptref{sp:async.pc}中概述的「作為一個簡單區塊鏈的支付通道」在這裡變得很方便。現在，我們考慮一個更複雜的虛擬區塊鏈，其狀態包含一組這樣的未實現的「promises」，以及在這些承諾中鎖定的資金數額。無論是在異步情況下的兩個工作鏈，都必須明確地引用前一個區塊的hash。然而，總體機制仍然保持不變。

\nxsubpoint\label{sp:sm.pc.chal} \embt(Challenges for the
sophisticated payment channel smart contracts.) 請注意，雖然一個複雜的支付通道的最終狀態仍然很小，而且「清潔」的終結很簡單（如果雙方都同意他們的應付金額，且雙方都已簽署他們的協議，那麼就沒有其他事情要做），但是單方面的終結方法和懲罰欺詐行為的方法需要更為複雜。實際上，它們必須能夠接受不當行為的Merkle證明，並檢查支付通道區塊鏈的更複雜交易是否已被正確處理。

換句話說，支付通道的智能合約必須能夠使用Merkle證明，檢查它們的「hash有效性」，並且必須包含$\evtrans$和$\evblock$功能的實現（參見\ptref{sp:blk.transf}）對於支付通道的（虛擬）區塊鏈。

\nxsubpoint\label{sp:ton.smart.pc.supp} \embt(TON VM support for
"smart" payment channels.) TON VM，用於運行TON Blockchain智能合約的程式碼，能夠應對執行所需的"smart"或複雜支付通道的智能合約（參見\ptref{sp:sm.pc.chal}）。

此時，「一切皆為bag of cells」的模式（參見\ptref{sp:everything.is.BoC}）變得非常方便。由於所有的區塊（包括短暫支付通道區塊鏈的區塊）都被表示為bag of cells（並由一些代數資料類型描述），對於訊息和Merkle證明也是如此，Merkle證明可以輕易地嵌入到發送到支付通道智能合約的入站訊息中。Merkle證明的「hash條件」將自動被檢查，當智能合約訪問呈現的「Merkle證明」時，它將像使用相應代數資料類型的值一樣工作，儘管它是不完整的，樹的一些子樹被替換為包含省略子樹的Merkle hash的特殊節點。然後智能合約將使用該值，該值可能代表支付通道（虛擬）區塊鏈及其狀態的一個區塊，並將該區塊鏈的$\evblock$函數（參見\ptref{sp:blk.transf}）評估為這個區塊和前一個狀態。然後，計算要麼完成，並且最終狀態可以與區塊中的聲明相比，要麼在嘗試訪問缺失的子樹時拋出「absent node」異常，表示Merkle證明是無效的。

以這種方式，使用TON Blockchain智能合約實現智能支付通道區塊鏈的驗證程式碼變得相對直接。可以說，{\em TON 虛擬機內建了檢查其他簡單區塊鏈有效性的支持。}唯一的限制因素是要合併到智能合約的入站訊息中的Merkle證明的大小（即交易）。

\nxsubpoint\label{sp:pc.within.pc} \embt(Simple payment channel within
a smart payment channel.) 我們想討論在現有支付通道內創建一個簡單的（同步或非同步）支付通道的可能性。

雖然這可能看起來有點複雜，但它與\ptref{sp:pc.promises}中討論的「promises」相比，理解和實現並不困難。本質上，$A$承諾根據一些其他（虛擬）支付通道區塊鏈的最終結算向$B$支付最多$c$個硬幣，而不是承諾如果提供了一些hash問題的解決方案，則支付$c$個硬幣給另一方。一般來說，這個其他的支付通道區塊鏈甚至不需要在$A$和$B$之間；它可能涉及一些其他的參與者，例如$C$和$D$，分別希望將$c$和$d$個硬幣承諾到他們的簡單支付通道中。（這個可能性在\ptref{sp:virt.pc}中後來被利用。）

如果包圍的支付通道是不對稱的，那麼需要在兩個工作鏈中承諾兩個promises：如果「內部」簡單支付通道的最終結算產生了一個與$0\leq-\delta\leq c$的負最終不平衡值$\delta$，$A$將承諾支付$-\delta$個硬幣給$B$；如果$\delta$是正的，$B$將不得不承諾支付$\delta$個硬幣給$A$。另一方面，如果包圍的支付通道是對稱的，那麼可以通過$A$提交一個帶有參數$(c,d)$的「簡單支付通道創建」交易到單一支付通道區塊鏈（這將凍結屬於$A$的$c$個硬幣），然後由$B$提交一個特殊的「確認交易」（這將凍結屬於$B$的$d$個硬幣）。

我們期望內部支付通道非常簡單（例如，在\ptref{sp:simple.sync.pc}中討論的簡單同步支付通道），以最小化要提交的Merkle證明的大小。外部支付通道將必須是\ptref{sp:pc.promises}中描述的那種「smart」。


\mysubsection{支付通道網路，或「閃電網路」}\label{sect:lightning}

現在，我們準備討論TON支付的「閃電網路」，該網路使得任何兩個參與節點之間能夠實時進行金錢轉賬。

\nxsubpoint \embt(Limitations of payment channels.)  一個支付通道對於那些期望在他們之間有大量的金錢轉賬的雙方是有用的。但是，如果一個人只需要向特定的接收者轉賬一兩次，則與她建立支付通道將是不切實際的。除其他外，這將意味著在支付通道中凍結大量的金錢，而且還需要至少兩次區塊鏈交易。

\nxsubpoint \embt(Payment channel networks, or ``lightning networks''.)  支付通道網路通過使金錢沿著{\em chains}的支付通道進行轉賬，來克服支付通道的局限性。如果$A$想要向$E$轉賬，她不需要與$E$建立支付通道。擁有一條通過幾個中間節點連接$A$和$E$的支付通道鏈就足夠了---比如說，四個支付通道：從$A$到$B$，從$B$到$C$，從$C$到$D$，以及從$D$到$E$。

\nxsubpoint \embt(Overview of payment channel networks.)  回想一下，一個{\em 支付通道網路}，也被稱為「閃電網路」，由一系列參與節點組成，其中一些節點之間建立了長時間存在的支付通道。我們稍後將看到，這些支付通道必須是\ptref{sp:pc.promises}意義上的「smart」。當一個參與節點$A$想要向任何其他參與節點$E$轉賬時，她會嘗試在支付通道網路內找到連接$A$和$E$的路徑。當找到這樣的路徑時，她沿著這條路徑進行「鏈金錢轉賬」。

\nxsubpoint\label{sp:ch.money.tr} \embt(Chain money transfers.) 假設存在一條從$A$到$B$，從$B$到$C$，從$C$到$D$，以及從$D$到$E$的支付通道鏈。進一步假設$A$想要轉賬$x$個硬幣給$E$。

一個簡單的方法是沿著現有的支付通道向$B$轉賬$x$個硬幣，並要求他將錢進一步轉發給$C$。但是，不清楚為什麼$B$不簡單地為自己取走錢。因此，必須採用一種更複雜的方法，不需要所有參與方互相信任。

這可以如下實現。$A$生成一個大的隨機數$u$並計算其hash值$v=\Hash(u)$。然後她在與$B$的支付通道內創建一個承諾，如果出示一個帶有hash值$v$的數字$u$，她將支付$x$個硬幣給$B$（參見\ptref{sp:pc.promises}）。這個承諾包含$v$，但不包含$u$，這仍然是保密的。

之後，$B$在他們的支付通道中對$C$創建了一個類似的承諾。他不害怕給出這樣的承諾，因為他知道$A$給他的一個類似的承諾存在。如果$C$曾經出示hash問題的解決方案來收集$B$承諾的$x$個硬幣，那麼$B$將立即將此解決方案提交給$A$，以收集來自$A$的$x$個硬幣。

然後創建$C$對$D$和$D$對$E$的類似承諾。當所有承諾都到位時，$A$通過將解決方案$u$通告給所有參與方來觸發轉賬---或僅通告給$E$。

這個描述中省略了一些次要的細節。例如，這些承諾必須有不同的到期時間，且沿著鏈上承諾的金額可能會略有不同（$B$可能只承諾$x-\epsilon$個硬幣給$C$，其中$\epsilon$是一個事先約定的小過境費）。我們暫時忽略這些細節，因為它們對於理解支付通道如何工作以及它們如何在TON中實現並不太相關。


\nxsubpoint\label{sp:virt.pc} \embt(Virtual payment channels inside a chain of payment channels.) 考慮以下情境：假設$A$和$E$預計會互相進行大量的付款。他們可以在區塊鏈(blockchain)之間創建一個新的支付通道(payment channel)，但這仍然會相當昂貴，因為某些資金會被鎖定在這個支付通道中。另一種選擇是對於每筆付款使用在~\ptref{sp:ch.money.tr}中描述的鏈錢轉移(chain money transfers)。但是，這會涉及大量的網路活動和所有參與的支付通道中的大量虛擬區塊鏈(virtual blockchain)交易。

另一種方法是在連接$A$至$E$的支付通道網路(payment channel network)中建立一個虛擬支付通道(virtual payment channel)。為此，$A$和$E$為他們的付款創建一個(虛擬的)區塊鏈，好像他們要在區塊鏈中創建一個支付通道一樣。但是，他們不是在區塊鏈中創建支付通道智能合約(smart contract)，而是要求所有中間支付通道---連接$A$至$B$、$B$至$C$等的通道---在其中創建簡單的支付通道，並綁定到$A$和$E$創建的虛擬區塊鏈(參考~\ptref{sp:pc.within.pc})。換句話說，現在每個中間支付通道內都存在根據$A$和$E$之間的最終結算來轉移資金的承諾。

如果虛擬支付通道是單向的，那麼可以很容易地實施這些承諾，因為最終的失衡值$\delta$將是非正值，因此可以按照在~\ptref{sp:ch.money.tr}中描述的相同順序在中間支付通道中創建簡單的支付通道。他們的到期時間也可以以相同的方式設定。

如果虛擬支付通道是雙向的，情況就稍微複雜了。在這種情況下，應該將根據最終結算轉移$\delta$個硬幣的承諾分成兩個半承諾，如\ptref{sp:pc.within.pc}中所解釋的那樣：轉移$\delta^-=\max(0,-\delta)$個硬幣到前向方向，和轉移$\delta^+=\max(0,\delta)$到反向方向。這些半承諾可以在中間支付通道中獨立創建，一個半承諾鏈在從$A$到$E$的方向，另一個半承諾鏈在相反的方向。


\nxsubpoint\label{sp:lnet.find.path} \embt(Finding paths in the lightning network.) 關於在支付網路(payment network)中如何找到連接$A$和$E$的路徑，這一點到目前為止還沒有討論。如果支付網路不是太大，可以使用類似OSPF的協議：所有支付網路的節點創建一個覆蓋網路(overlay network)（參考~\ptref{sp:net.within.net}），然後每個節點都通過gossip協議將所有可用鏈接（即，參與的支付通道）信息傳播給其鄰居。最終，所有節點都將擁有支付網路中所有參與的支付通道的完整列表，並且將能夠自己找到最短的路徑---例如，應用一個修改過的Dijkstra算法版本，以考慮到涉及的支付通道的"容量"（即，可以沿著它們傳輸的最大金額）。一旦找到了一個候選路徑，它可以被一個特殊的ADNL數據包探測，該數據包包含完整的路徑，並要求每個中間節點確認所涉及的支付通道的存在，並根據路徑將此數據包進一步轉發。之後，可以構建一條鏈，並可以運行鏈轉移（參考~\ptref{sp:ch.money.tr}）或在支付通道鏈中創建虛擬支付通道的協議（參考~\ptref{sp:virt.pc}）。

\nxsubpoint \embt(Optimizations.) 在此處可以進行一些優化。例如，只有閃電網路(lightning network)的中繼節點需要參與在~\ptref{sp:lnet.find.path}中討論的類似OSPF的協議。兩個“葉子”節點希望通過閃電網路連接，將他們連接到的中繼節點列表（即，他們已建立的參與支付網路的支付通道）通告給對方。然後，可以如上所述檢查從一個列表中的中繼節點到另一個列表中的中繼節點的路徑~\ptref{sp:lnet.find.path}。

\nxsubpoint \embt(Conclusion.) 我們已經概述了如何使用TON專案的區塊鏈和網路技術來創建{\em TON Payments}，這是一個用於鏈外即時金錢轉賬和小額支付的平台。對於居住在TON生態系中的服務，這個平台可能非常有用，允許它們在需要的時候和地方輕鬆收集小額支付。


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%                  CONCLUSION
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\clearpage
\section*{結論}
\markbothsame{\textsc{Conclusion}}
\addcontentsline{toc}{section}{結論}

我們已提出一個可擴展的多區塊鏈架構，能夠支持大量流行的加密貨幣和具有用戶友好界面的去中心化應用程式。

為了達到必要的可擴展性，我們提出了{\em TON Blockchain}，一個``緊密耦合''的多區塊鏈系統（參見~\ptref{sp:blkch.interact}），該系統採用了自下而上的分片方法（參見~\ptref{sp:shard.supp}和~\ptref{sp:ISP}）。為了進一步提高潛在性能，我們引入了2區塊鏈機制來替換無效的區塊（參見~\ptref{sp:inv.sh.blk.corr}）以及Instant Hypercube Routing以實現分片之間的更快通訊（參見~\ptref{sp:instant.hypercube}）。與現有和提議的區塊鏈專案的簡短比較（參見~\ptref{sect:class.blkch}和~\ptref{sect:compare.blkch}）突顯了這種方法對於尋求每秒處理百萬交易的系統的好處。

在第~\ptref{sect:network}章中描述的{\em TON Network}，滿足了所提議的多區塊鏈基礎設施的網路需求。此網路組件還可與區塊鏈結合使用，以創建一系列應用程式和服務，僅使用區塊鏈無法實現（參見~\ptref{sp:blockchain.facebook}）。在第~\ptref{sect:services}章中討論的這些服務包括{\em TON DNS}，一個用於將人類可讀的對象識別符翻譯成其地址的服務；{\em TON Storage}，一個用於儲存任意文件的分佈式平台；{\em TON Proxy}，一個用於匿名化網路訪問和訪問TON驅動服務的服務；以及{\em TON Payments\/}（參見第~\ptref{sect:payments}章），這是一個用於在TON生態系統中進行即時鏈下資金轉移的平台，應用程式可用於小額支付。

TON基礎設施允許專門的輕量客戶端錢包和``ton-browser''桌面和智能手機應用程式，為最終用戶提供類似瀏覽器的體驗（參見~\ptref{sp:ton.www}），使加密貨幣支付以及與TON平台上的智能合約和其他服務的互動對大眾用戶來說是可訪問的。這樣的輕量客戶端可以集成到Telegram Messenger客戶端中（參見~\ptref{sp:telegram.integr}），從而最終將基於區塊鏈的應用程式帶給數以億計的用戶。

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%                  BIBLIOGRAPHY
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\clearpage
\markbothsame{\textsc{References}}

\begin{thebibliography}{2}

\bibitem{Birman}
  {\sc K.~Birman}, {\sl Reliable Distributed Systems: Technologies, Web Services and Applications}, Springer, 2005.
  
\bibitem{EthWP}
  {\sc V.~Buterin}, {\sl Ethereum: A next-generation smart contract and decentralized application platform}, \url{https://github.com/ethereum/wiki/wiki/White-Paper}, 2013.

\bibitem{BenOr}
  {\sc M.~Ben-Or, B.~Kelmer, T.~Rabin}, {\sl Asynchronous secure computations with optimal resilience}, in {\em Proceedings of the thirteenth annual ACM symposium on Principles of distributed computing}, p.~183--192. ACM, 1994.

\bibitem{PBFT}
  {\sc M.~Castro, B.~Liskov, et al.}, {\sl Practical byzantine fault tolerance}, {\it Proceedings of the Third Symposium on Operating Systems Design and Implementation\/} (1999), p.~173--186, available at \url{http://pmg.csail.mit.edu/papers/osdi99.pdf}.

\bibitem{EOSWP}
  {\sc EOS.IO}, {\sl EOS.IO technical white paper}, \url{https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md}, 2017.

\bibitem{Onion}
  {\sc D.~Goldschlag, M.~Reed, P.~Syverson}, {\sl Onion Routing for Anonymous and Private Internet Connections}, {\it Communications of the ACM}, {\bf 42}, num.~2 (1999), \url{http://www.onion-router.net/Publications/CACM-1999.pdf}.

\bibitem{Byzantine}
  {\sc L.~Lamport, R.~Shostak, M.~Pease}, {\sl The byzantine generals problem}, {\it ACM Transactions on Programming Languages and Systems}, {\bf 4/3} (1982), p.~382--401.

\bibitem{BitShWP}
  {\sc S.~Larimer}, {\sl The history of BitShares}, \url{https://docs.bitshares.org/bitshares/history.html}, 2013.

\bibitem{RaptorQ}
  {\sc M.~Luby, A.~Shokrollahi, et al.}, {\sl RaptorQ forward error correction scheme for object delivery}, IETF RFC 6330, \url{https://tools.ietf.org/html/rfc6330}, 2011.

\bibitem{Kademlia}
  {\sc P.~Maymounkov, D.~Mazi\`eres}, {\sl Kademlia: A peer-to-peer information system based on the XOR metric}, in {\em IPTPS '01 revised papers from the First International Workshop on Peer-to-Peer Systems}, p.~53--65, available at \url{http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf}, 2002.

\bibitem{HoneyBadger}
  {\sc A.~Miller, Yu Xia, et al.}, {\sl The honey badger of BFT protocols}, Cryptology e-print archive 2016/99, \url{https://eprint.iacr.org/2016/199.pdf}, 2016.

\bibitem{BitcWP}
  {\sc S.~Nakamoto}, {\sl Bitcoin: A peer-to-peer electronic cash system}, \url{https://bitcoin.org/bitcoin.pdf}, 2008.

\bibitem{STGM}
  {\sc S.~Peyton Jones}, {\sl Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine}, {\it Journal of Functional Programming\/} {\bf 2} (2), p.~127--202, 1992.

\bibitem{Raptor}
  {\sc A.~Shokrollahi, M.~Luby}, {\sl Raptor Codes}, {\it IEEE Transactions on Information Theory\/} {\bf 6}, no.\ 3--4 (2006), p.~212--322.

\bibitem{DistrSys}
  {\sc M.~van Steen, A.~Tanenbaum}, {\sl Distributed Systems, 3rd ed.}, 2017.

\bibitem{HoTT}
  {\sc The Univalent Foundations Program}, {\sl Homotopy Type Theory: Univalent Foundations of Mathematics}, Institute for Advanced Study, 2013, available at \url{https://homotopytypetheory.org/book}.

\bibitem{PolkaWP}
  {\sc G.~Wood}, {\sl PolkaDot: vision for a heterogeneous multi-chain framework}, draft~1, \url{https://github.com/w3f/polkadot-white-paper/raw/master/PolkaDotPaper.pdf}, 2016.

\end{thebibliography}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%                  APPENDICES
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\appendix
\myappendix{Toncoin，又名TON}\label{app:coins}

TON區塊鏈的主要加密貨幣，特別是其主鏈和基本工作鏈，是{\em Toncoin}，也被稱為{\em Toncoin\/} (TON)。它被用於進行成為validator所需的存款；交易費、gas支付（即，智能合約消息處理費）和持久儲存支付通常也以Toncoin收取。

\nxpoint \embt(Subdivision and terminology.)  一個{\em Toncoin\/}被細分為十億 ($10^9$) 更小的單位，稱為{\em nanoToncoin}、{\em nToncoin}或簡單地稱為{\em nanos}。所有的轉賬和賬戶餘額都表示為nanos的非負整數倍。其他單位包括：
\begin{itemize}
\item 一個{\em nano}、{\em nToncoin}或{\em nanoToncoin}是最小的單位，等於 $10^{-9}$ Toncoin。
\item 一個{\em micro\/}或{\em microToncoin\/}等於一千($10^3$) nanos。
\item 一個{\em milli\/}等於一百萬 ($10^6$) nanos，或一個Toncoin的千分之一 ($10^{-3}$)。
\item 一個{\em Toncoin\/}等於十億 ($10^9$) nanos。
\item 一個{\em kiloToncoin}、或{\em kToncoin}，等於一千 ($10^3$) Toncoin。
\item 一個{\em megaToncoin}、或{\em MToncoin}，等於一百萬 ($10^6$) Toncoin，或 $10^{15}$ nanos。
\item 最後，一個{\em gigaToncoin}、或{\em GToncoin}，等於十億 ($10^9$) Toncoin，或 $10^{18}$ nanos。
\end{itemize}

不需要更大的單位，因為Toncoin的初始供應量將限制為五十億 ($5\cdot10^9$) Toncoin (即，5 GigaToncoin)。

\nxpoint \embt(Smaller units for expressing gas prices.)  如果出現需要更小單位的必要性，將使用等於 $2^{-16}$ nanoToncoin的``specks''。例如，gas價格可能以specks表示。然而，實際要支付的費用，計算為gas價格和消耗的gas量的乘積，將始終四捨五入到最接近的 $2^{16}$ specks的倍數，並表示為nanos的整數。


\nxpoint \embt(Original supply, mining rewards and inflation.)  Toncoin的總供應量原本限制為$5$ GigaToncoin (即，五十億的Toncoin或$5\cdot10^{18}$ nanos)。

這一供應量將非常緩慢地增加，因為獎勵給validator挖掘新的主鏈和分片鏈區塊積累。這些獎勵大約會達到$20\%$ (確切的數字可能在未來進行調整)的validator的每年股份，只要validator努力履行其職責，簽署所有區塊，從不離線並且從不簽署無效的區塊。這樣，validator將有足夠的利潤投資於更好更快的硬體，以處理不斷增加的用戶交易量。

我們預計最多$10\%$\footnote{validator股份的最大總量是區塊鏈的一個可配置參數，因此如果需要，該協議可以強制執行此限制。}的Toncoin總供應量，平均下來，將在任何給定時刻被validator股份綁定。這將產生一個$2\%$的每年的通脹率，並因此，在35年內將Toncoin的總供應量加倍(到十個GigaToncoin)。從本質上講，這種通脹代表了由社區的所有成員支付給validator的款項，用於保持系統正常運行。

另一方面，如果一個validator被抓到有不正當行為，其部分或全部的股份將被作為懲罰而扣除，並且其中的較大部分隨後將被“銷毀”，從而減少Toncoin的總供應量。這將導致通貨緊縮。罰款的一小部分可能會重新分配給validator或提交有罪validator不當行為證明的“fisherman”。

\nxpoint\label{sp:Toncoin.price} \embt(Original price of Toncoin.)  第一個要出售的Toncoin的價格將約等於$\$0.1$ (USD)。每一個接下來要被賣出的Toncoin (由TON儲備，由TON基金會控制) 都將比前一個價格高十億分之一。這樣，要放入流通的第$n$個Toncoin將以大約
\begin{equation}\label{eq:Toncoin.price}
  p(n)\approx 0.1\cdot (1+10^{-9})^n\quad\text{USD},
\end{equation}
或其他(加密)貨幣的大約相等的金額（由於市場匯率迅速變化），如BTC或ETH，出售。

\nxsubpoint\label{sp:exp.priced} \embt(Exponentially priced cryptocurrencies.)  我們稱Toncoin為一種{\em exponentially priced cryptocurrency}，意思是將要流通的第$n$個Toncoin的價格大約為$p(n)$，由以下公式給出
\begin{equation}
  p(n)=p_0\cdot e^{\alpha n}
\end{equation}
具體值為$p_0=0.1$ USD 和 $\alpha=10^{-9}$。

更精確地說，一個新硬幣的小部分$dn$價值為$p(n)\,dn$美元，一旦$n$個硬幣流通。(這裡的$n$不必然是整數。)

這種加密貨幣的其他重要參數包括$n$，流通中的硬幣總數，和$N\geq n$，可以存在的硬幣總數。對於Toncoin，$N=5\cdot 10^9$。

\nxsubpoint \embt(Total price of first $n$ coins.)  第一個$n$個以指數方式定價的加密貨幣(例如，Toncoin)要流通的總價$T(n)=\int_0^n p(n)\,dn\approx p(0)+p(1)+\cdots+p(n-1)$可以通過以下方式計算
\begin{equation}
  T(n)=p_0\cdot\alpha^{-1}(e^{\alpha n}-1)\quad.
\end{equation}

\nxsubpoint \embt(Total price of next $\Delta n$ coins.)  在先前存在的$n$個硬幣之後流通的$\Delta n$個硬幣的總價$T(n+\Delta n)-T(n)$可以通過以下方式計算
\begin{equation}\label{eq:T.m.n}
  T(n+\Delta n)-T(n)=p_0\cdot\alpha^{-1}(e^{\alpha(n+\Delta n)}-e^{\alpha n})
  =p(n)\cdot\alpha^{-1}(e^{\alpha\,\Delta n}-1)\quad.
\end{equation}

\nxsubpoint \embt(Buying next coins with total value $T$.)  假設已經有$n$個硬幣流通，並且有人想花$T$ (美元)購買新硬幣。新獲得的硬幣數量$\Delta n$可以通過將$T(n+\Delta n)-T(n)=T$放入\eqref{eq:T.m.n}中來計算，得到
\begin{equation}\label{eq:new.coins}
  \Delta n=\alpha^{-1}\log\left(1+\frac{T\cdot\alpha}{p(n)}\right)\quad.
\end{equation}
當然，如果$T\lll p(n)\alpha^{-1}$，那麼$\Delta n\approx T/p(n)$。


\nxsubpoint \embt(Market price of Toncoin.)  當然，如果自由市場價格跌破$p(n):=0.1\cdot (1+10^{-9})^n$，一旦$n$個Toncoin流通，沒有人會從TON Reserve購買新的Toncoin；他們會選擇在自由市場上購買Toncoin，而不增加Toncoin的總流通量。另一方面，一個Toncoin的市場價格不能比$p(n)$高得多，否則從TON Reserve獲得新的Toncoin是有意義的。這意味著Toncoin的市場價格不會受到突如其來的劇烈波動(和下跌)；這很重要，因為 stake (validator deposits)至少被凍結了一個月，而且gas價格也不能改變得太快。所以，系統的整體經濟穩定性需要一個機制，防止Toncoin的匯率發生過於劇烈的變化，就像上面描述的那樣。

\nxsubpoint \embt(Buying back the Toncoin.)  如果Toncoin的市場價格跌到$0.5\cdot p(n)$以下，當總共有$n$個Toncoin流通(即，不保留在TON Reserve控制的特殊帳戶上)，TON Reserve保留購回一些Toncoin並減少$n$，即Toncoin的總流通量的權利。這可能是為了防止Toncoin匯率突然下跌。

\nxsubpoint \embt(Selling new Toncoin at a higher price.)  TON Reserve將只根據價格公式~\eqref{eq:Toncoin.price}銷售最多一半(即，$2.5\cdot10^9$ Toncoin)的Toncoin總供應量。它保留不銷售任何剩餘的Toncoin，或以高於$p(n)$的價格出售它們，但永遠不會以較低的價格出售(考慮到匯率快速變化的不確定性)。這裡的道理是，一旦至少一半的Toncoin都被賣出，Toncoin市場的總價值將足夠高，外部力量操縱匯率比在Toncoin部署初期可能更困難。

\nxpoint\label{sp:unalloc.gr} \embt(Using unallocated Toncoin.)  TON Reserve將使用大部分的``未分配''Toncoin(大約$5\cdot10^9-n$ Toncoin)---即，那些存在於TON Reserve的特殊帳戶和與之明確關聯的其他帳戶中的Toncoin---只作為validator stakes (因為TON基金會本身可能必須在TON區塊鏈的第一個部署階段提供大部分的validators)，和在主鏈上投票支持或反對有關``可配置參數''和其他協議更改的提案，由TON基金會決定(即，其創建者---開發團隊)。這也意味著在TON Blockchain的第一個部署階段，TON基金會將擁有大多數的票。希望那時系統會變得更加成熟，不需要太頻繁地調整參數。

\nxsubpoint\label{sp:dev.Toncoin} \embt(Some unallocated Toncoin will be
given to developers.)  一預定的（相對較少的）「未分配」的Toncoin數量（例如，200 MegaToncoin，相當於總供應的4％）將在TON Blockchain的部署期間轉移到由TON Foundation控制的特殊賬戶，然後某些「獎勵」可能會從此賬戶支付給開源TON軟體的開發者，並有最少兩年的鑲嵌期。

\nxsubpoint\label{sp:TON.own.Toncoin} \embt(The TON Foundation needs
Toncoin for operational purposes.)  請記住，TON Foundation將收到由TON Reserve出售的Toncoin所得的法定貨幣和加密貨幣，並將其用於TON Project的開發和部署。例如，原始的validator集合以及TON Storage和TON Proxy節點的初始集合可能由TON Foundation安裝。

雖然這對於項目的快速啟動是必要的，但最終目標是使該項目盡可能去中心化。為此，TON Foundation可能需要鼓勵安裝第三方validator以及TON Storage和TON Proxy節點 - 例如，通過支付他們儲存TON Blockchain的舊區塊或代理所選服務子集的網絡流量。此類付款將以Toncoin進行；因此，TON Foundation將需要大量的Toncoin用於操作目的。

\nxsubpoint \embt(Taking a pre-arranged amount from the Reserve.) TON Foundation將從TON Reserve轉賬到其賬戶的一小部分 - 說，所有硬幣的10％（即500 MegaToncoin）在Toncoin的初次銷售結束後 - 用於其自己的目的，如在~\ptref{sp:TON.own.Toncoin}中概述的。最好是與為TON開發人員提供的資金轉賬同時完成，如在~\ptref{sp:dev.Toncoin}中提到的。

在轉移到TON Foundation和TON開發人員之後，TON Reserve價格$p(n)$的Toncoin將立即上升一定量，這一量是提前知道的。例如，如果所有硬幣的10％被轉移用於TON Foundation的目的，而4％被轉移以鼓勵開發者，則流通中的硬幣總數量$n$將立即增加$\Delta n=7\cdot10^8$，Toncoin的價格乘以$e^{\alpha\,\Delta n}=e^{0.7}\approx 2$（即，加倍）。


剩餘的「未分配」Toncoin將由TON Reserve使用，如上面的~\ptref{sp:unalloc.gr}所解釋。如果TON Foundation之後還需要更多的Toncoin，它將簡單地將其在硬幣銷售期間先前獲得的部分資金轉換為Toncoin，無論是在自由市場還是從TON Reserve購買Toncoin。為了防止過度中心化，TON Foundation永遠不會努力在其帳戶上擁有超過總Toncoin數量的10％（即500 MegaToncoin）。

\nxpoint\label{sp:bulk.sales} \embt(Bulk sales of Toncoin.) 當很多人同時想從TON Reserve購買大量Toncoin時，最好不要立即處理他們的訂單，因為這將導致結果非常依賴於特定訂單的時機和他們的處理順序。

相反，購買Toncoin的訂單可能在某個預定的時間段（例如，一天或一個月）內收集，然後一次全部處理。如果收到$k$個訂單，第$i$個訂單價值$T_i$美元，則總金額$T=T_1+T_2+\cdots+T_k$用於根據\eqref{eq:new.coins}購買$\Delta n$新硬幣，並且第$i$個訂單的發送者分配了這些硬幣的$\Delta n\cdot T_i/T$。這樣，所有買家都以每Toncoin $T/\Delta n$ USD的相同平均價格獲得他們的Toncoin。

之後，收集購買新Toncoin的訂單的新一輪開始。

當Toncoin購買訂單的總價值變得足夠低時，這種「批量銷售」系統可能會被一個根據公式~\eqref{eq:new.coins}從TON Reserve立即銷售Toncoin的系統所替代。

「批量銷售」機制可能在收集TON Project投資的初始階段得到廣泛使用。

\end{document}