The Gold Blockchain is actually a set and registry of blockchains (to be clarified in 2.1.17), because no ordinary blockchain is able to achieve the goal of processing millions of transactions per second, unlike the standard blockchain that exists today, where the transaction speed does not exceed a dozen per second.

2.1.1. A list of the types of blockchains. Introducing :

* A unique master blockchain or masterchain masterchain, containing general information about the protocol and the current values of its parameters, a set of validators and their shares, a set of currently active working chains and their "segments", and most importantly, a set of hashes of the last blocks of all chains and segments.

• Several (up to 2³²) workchains, the workchains blockchain for short, are "workhorses" containing the transfer of the value of a smart contract transaction. Different work chains can have different "rules", which means different account address formats, different transaction formats, different virtual machines for smart contracts, different major cryptocurrencies, and so on. However, they all need to meet some basic interoperability criteria for interaction between different workspaces, and should be relatively simple. In this respect, the Gold Blockchain is heterogeneous (see 6.1.8), similar to EOS (see 6.2.7) and the PolkaDot project (see 6.2.8).

• Each work chain, in turn, is subdivided into 2⁶⁰ block segments, or shardchains for short, having the same block rules and format as the work chain itself, but is responsible only for accounts, depending on the first few (most significant) bits of the account account address. In other words, a segmentation form is built into the system (see 6.1.12). Since all these segments share a common block format and rules, the AUR Blockchain is homogeneous in this respect (see 6.1.8), similar to what was discussed in one of the Ethereum scaling proposals.¹

1 https: //github.com/ethereum/wiki/wiki/Sharding-FAQ

• Each block in shardchain (and in masterchain) is actually not just a block, but a small blockchain. Usually this "blockchain" or "vertical blockchain" consists of exactly one block, and then we can think that it is just the corresponding shardchain block (also called "horizontal blockchain" in this situation). However, if it becomes necessary to correct incorrect shardchain blocks, the new block is fixed in the "vertical blockchain", containing either a replacement of the invalid block "horizontal blockchain" or "block difference", containing only a description of those parts of the previous version of this block that need to be changed. This is a specific mechanism for replacing detected invalid blocks, without creating a true fork of all segments; this will be explained in more detail in 2.1.17. For now, we'll just note that each shardchain (and masterchain) segment is not a regular blockchain, it's a blockchain of sidechains or a 3D blockchain.

2.1.2. The infinite paradigm. Almost all blockchain segmentation proposals are "top-down": first, a single blockchain is presented, and then it is discussed how to divide it into several interacting segments to improve performance and scalability. Gold Digital's bottom-up segmentation approach is explained as follows. Imagine that the segment has been pushed to the limit, so that exactly one account or smart contract remains in each shardchain. Then we have a huge number of "account chains", each of which describes the state and state transitions of only one account and sends valuable messages to each other with the transfer cost and information. Of course, it is not practical to have hundreds of millions of blocks, with updates (i.e. new blocks) that usually appear quite infrequently in each of them. To implement them more efficiently, we group these "accounts" into segments, so that each sharding block is essentially a collection of accounts-chains that have been assigned to this segment. Thus, "accounting chains" have only a purely virtual or logical existence within "segments". We call this perspective the infinite segmentation paradigm. This explains many of the design decisions for the Gold Blockchain.

2.1.3. Messages. Instant Hypercube routing. The infinite Segmentation paradigm instructs us to treat each account (or smart contract) as if it were on its own. Then the only way that one account could influence the state of another is to send messages (this is a special instance of the so-called Actor model with accounts as Actors). Therefore, the system of communication between accounts (and shardchains, because the source and target accounts are, generally speaking, located in different shardchains) is of paramount importance for a scalable system such as the Gold Blockchain. In fact, a new feature of the Gold Blockchain, called Instant Hypercube routing, allows you to deliver and process a message created in a block of one shardchain to the very next block that is not related to the total number of segments in the system.

2.1.4. The number of masterchains, workchains, and shardchains. The Gold Blockchain contains exactly one masterchain. However, the system can accommodate up to 2³² workchains, each of which is subdivided into up to 2⁶⁰ shardchains segments.

2.1.5. Workchains can be virtual blockchains, but not true blockchains. Since the workchain is subdivided into shardchains, the existence of the workchain is "virtual", which means that it is not a true blockchain in the sense of the general definition given in paragraph, but simply a registry of shardchains segments. When only one shardchain segment matches the workchain, this unique shardchain can be identified with the workchain, which in this case becomes the "true" blockchain, at least for some time, thereby obtaining a super-similarity with the usual single-chain blockchain. However, the Infinite Segmentation Paradigm (see 2.1.2) tells us that this similarity is indeed superficial: this is just a coincidence, because a potentially huge number of "accounts" can be temporarily grouped into one chain and one blockchain.

2.1.6. Identification of workchains. Each workchain is identified by its own number or workchain ID (workchain_id: uint32), which is simply an unsigned 32-bit integer. Workchains jobs are created by special transactions in the masterchain, defining a (previously unused) work chain ID and a formal description of the workchain work chain, sufficient at least for the interaction of this work chain with other work targets and for the surface verification of this workchain block.

2.1.7. Creation and activation of new jobs. The creation of a new workchain can be initiated by almost any member of the community who is willing to pay the (high) transaction fee in masterchain required to publish the formal specification of the new workchain. However, in order for the new workchain working chain to become active, the consent of two-thirds of the validators is required, because they will need to update their software to process the blocks of the new workchain and declare their readiness to work with the new workchain working chain under a special deal with masterchain. A party interested in activating the new workchain work chain can provide an incentive for validators to support the new workchain work chain through some rewards distributed through a smart contract.

2.1.8. Segment identification. Each segment is identified by a pair (w, s) = (workchain_id, shard_prefix), where workchain_id: uint32 identifies the corresponding workchain work chain, and the shard_prefix segment: 2^{0 ... 60} bit string of no more than 60, defines the subset of accounts for which this shardchain segment is responsible. Namely, all accounts with account_id starting with shard_prefix (i.e. with shard_prefix as the most significant bits) will be assigned to this chain segment.

2.1.9. Identification of chain accounts. Recall that account networks have a virtual existence (see 2.1.2). However, they have a natural identifier, namely: (workchain_id, account_id), since any chain of accounts contains information about the status and updates of only one account (either a simple account or a smart contract, the difference is not important here).

2.1.10. Dynamic segment splitting and merging; see 2.7. A less complex system can use static segmentation - for example, using the top eight bits of account_id to select one of 256 predefined segments. An important feature of the Gold Blockchain is that it implements dynamic segmentation and this means that the number of chain segments is not fixed. A shard segment (w, s) can be automatically subdivided into segments (w, s.0) and (w, s.1) if some formal conditions are met (essentially, if the transaction load on the initial segment is high enough for a long period of time). Conversely, if the load remains too low for a certain period of time, the segments (w, s.0) and (w, s.1) can be automatically merged back into the segment (w, s). Initially, only one segment (w,∅) is created for the workchain w. This is later subdivided into a large number of segments (shards) when it becomes necessary (see 2.4.6 and 2.4.8).

2.1.11. The main working chain is workchain or Workchain Zero. While up to 2³² workchains can be defined with their specific rules and transactions, we initially define only one, with workchain_id = 0. This working chain, called Workchain Zero or the main working chain, is the one that is used to work with Gold smart contracts and transfers Gold coins, known as AUR. Most applications will probably only require Workchain Zero. The segments of the main workchain will be called base shardchains.

2.1.12. Block generation intervals. We expect a new block to be created in shardchain and masterchain about once every five seconds. This will result in a reasonably short transaction confirmation time. New blocks of all segments are generated about simultaneously; a new masterchain block is generated about a second later, because it must contain hashes of the last blocks of all segments.

2.1.13. Using the masterchain workshop to create workchains chains and shardchains segments are closely related. After the hash of a shardchain block is included in the masterchain block chain, this shardchain block and all its ancestors are considered "canonical", which means that they can be referenced from a subsequent block of all segments as something fixed and unchangeable. In fact, each new shardchain block contains a hash from the last masterchain block, and all shardchain blocks referenced by this masterchain main chain block are considered unchanged to the new block. Essentially, this means that a transaction or message committed to a shardchain block can be safely used in the very next blocks of another shardchains, without having to wait for, say, 20 confirmations (i.e., twenty blocks generated after the original block in the same block chain) before forwarding the message or taking other actions based on the previous transaction, as is customary in most of the proposed "loosely coupled" systems (see 6.1.14), such as EOS. This ability to use transactions and messages in other segments just five seconds after they are committed is one of the reasons why we claim that our "tightly coupled" system, the first of its kind, will be able to deliver unprecedented performance (see 6.1.12 and 6.1.14).

2.1.14. Hash of the Masterchain block as a global state. According to clause 2.1.13, the hash of the last block chain completely determines the overall state of the system from the point of view of an external observer. You don't need to monitor the state of all shardchains segments separately.

2.1.15. Generating new blocks using validators; see 2.6. Gold Blockchain uses the proof-of-stake (PoS) approach to generate new blocks in the shardchains and main masterchain segments. This means that there is a set of, say, up to several hundred validators-special nodes that have deposited shares (a large number of AUR coins) using a special deal with masterchain to obtain the rights to create and validate a new block. Each segment (w, s) is then assigned a smaller subset of validators in a deterministic pseudo-random path that changes approximately every 1024 blocks. This subset of validators proposes and achieves consensus on the next shardchain block to be created by collecting suitable proposed transactions from clients about new valid block candidates. For each block, there is a pseudo-randomly selected order on the validators to determine which block candidate has the highest priority to be committed at each step.

Validators and other nodes verify the validity of the proposed block candidates; if a validator signs an invalid block candidate, it can be automatically penalized by losing part and all of its share, or by being suspended from the validator set for some time. After that, the validators must reach a consensus on choosing the next block, essentially an effective BFT option (Byzantine Rejection of Tolerance, see 6.1.4), an agreed protocol similar to PBFT [4] or Honey Badger BFT [11]. If a consensus is reached, a new block is created, and the validators share the transaction fees among themselves, including transactions, as well as some newly created ("minted") coins. Each validator can be selected to participate in several subsets of validators; in this case, all the validation and matching algorithms are expected to run in parallel with each other. After new shardchain blocks are created or a timeout is passed, a new masterchain block is generated, including the hashes of the last blocks of all segments. This is done by the BFT consensus of all validators.² For more information about the Gold PoS approach and its economic model, see section 2.3.

2 In fact, two-thirds of the bid is sufficient to reach a consensus, but efforts are being made to collect as many signatures as possible

2.1.16. The forks (forks) masterchain. The complication that arises from our tightly coupled approach is that switching to another fork in the masterchain will almost certainly require switching to another fork of some of the shardchains segments. On the other hand, as long as there are no forks in the masterchain master chain, no forks in the shardchain are even possible, because there are no blocks in the alternative forks of the shardchain segments that can become "canonical" with their hashes included in the masterchain. The general rule is that if the masterchain block B0 is the predecessor of B, B0 includes the Hash Hash (B0 w, s) of the block (w, s) - the shardchain segment B0 w, s and B includes the Hash Hash (Bw, s), then B0 w, s must be the predecessor of Bw, s; otherwise, the masterchain block B is invalid. We expect that manipulator forks will be rare, next to non-existent, because in the BFT paradigm adopted by Gold Blockchain, they can only happen if the majority of validators behave incorrectly (see 2.3.1 and 2.3.15), which will mean significant losses on the part of offenders. Therefore, you should not expect true forks in shardchains segments. If an invalid shardchain block is detected, it will be corrected using the "vertical blockchain" 2-blockchain mechanism (see 2.1.17), which can achieve this goal without imposing a "horizontal blockchain" (i.e., shardchain). The same mechanism can be used to eliminate non-critical errors in the masterchain block.

2.1.17. Correction of invalid shardchain blocks. Normally, only valid shardchain blocks can be created, as validators assigned to shardchain must reach two-thirds of the Byzantine consensus before creating a new block. However, the system must be able to detect previously committed invalid blocks and correct them. Of course, once an invalid shardchain block is found - either by a validator (not necessarily this shardchain) or by a " fisherman "(any node of the system that has made a certain deposit to be able to ask questions about the validity of the block; see 2.3.4), an application for invalidity and its proof is submitted to masterchain, and validators who signed an invalid block are punished with the loss of part of their share and / or temporary suspension of work from the set of validators (the latter measure is important in the case when an attacker steals the private signature keys of another good validator). However, this is not enough, as the state of the shared system (Gold Blockchain) is rendered invalid due to an invalid shardchain segment. This invalid block must be replaced with a new block of the valid version. In most systems, this is achieved by "rolling back" to the last block facing the invalid one in this shardchain and the last blocks not affected by the messages propagate from the invalid block in each of the other shardchains segments and create a new fork from these blocks. This approach has the disadvantage that a large number of other correct and committed transactions will suddenly make a rollback, and it is not clear if they will be included later.

Gold Blockchain solves this problem by making each "block", each shardchain and masterchain segment ("horizontal blockchains") a small blockchain ("vertical blockchain") containing different versions of this" block "or their"differences". Usually, a vertical blockchain consists of exactly one block, and a shardchain segment looks like a classic blockchain. However, once the invalidity of the block is confirmed and passed to the masterchain ,the" vertical blockchain " of the invalid block allows for the growth of new blocks in the vertical direction, replacing or editing the invalid block. The new block is generated by the current subset of validators for the shardchain segment. The rules for the new "vertical" block should be quite strict. In particular, if the virtual "account block chain" (see 2.1.2) contained in the invalid block is valid on its own, it must remain unchanged with the new vertical block. As soon as a new "vertical" block is created over an invalid block, its hash is published in the new masterchain block (or rather, in the new "vertical" block lying above the original masterchain block, where the hash of the invalid shardchain block was originally published) and the changes are propagated further to any shardchain blocks related to the previous version of this block (for example, those that received messages from the wrong block).

This is fixed by entering new "vertical" blocks into the vertical blockchains for all blocks that have a reference to the "wrong" block; the new vertical blocks will link to the latest (corrected) versions. Again, strict rules prohibit changing the chain of accounts that are not actually affected (that is, that receive the same messages as in the previous version). Thus, fixing the wrong block generates a "ripple" that eventually spreads for the most part to the last blocks of all the affected segments.; these changes are reflected in the new "vertical" blockchains. After the ripple of "rewriting history" reaches the most recent blocks, new Segment Blocks are generated in only one version, being the successors of only the newest block versions. This means that they will contain links to the correct (most recent) vertical blocks from the very beginning. The state of the masterchain master chain implicitly defines a map that converts the hash of the first block of each "vertical" blockchain to the hash of its latest version. This allows the client to identify and find any vertical blockchain using the hash of its very first (and usually only) block.

2.1.18. Gold and multi-currency workchains .

Gold Blockchain supports up to 2 ³² different "cryptocurrencies", "coins" or "tokens" that differ in the 32-bit currency_id. You can add new cryptocurrencies for special deals in the masterchain workshop. Each workchain has a base cryptocurrency and can have several additional cryptocurrencies. There is one special cryptocurrency with currency_id = 0, namely: Gold, also known as AUR (see Appendix A). This is the base cryptocurrency of Workchain Zero. It is also used to pay for transactions and validator bids. Basically, other workchains can charge a commission for transactions in other tokens. In this case, some smart contracts should be provided to automatically convert these transaction fees to AUR.

2.1.19. Message passing and value transfer. Shardchains segments that belong to the same or different workchains can send messages to each other. The exact form of allowed messages depends on the receiving workchain work chain and the receiving account (smart contract), there are some common fields of possible messages between the workchain work chains. In particular, each message can have some value in the form of a certain number of AUR coins and / or other registered cryptocurrencies, if they are declared acceptable cryptocurrencies for the receiving workchain. The simplest form of such messaging is the transfer of value from one account to another.

2.1.20. Gold virtual machine. A Gold virtual machine, also abbreviated as a Gold VM or GVM, is a virtual machine used to execute smart contract code in the masterchain main chain and in the workchain main work chain. Other workchains can use other virtual machines instead of GVM. Some of its functions are listed here. They are discussed further in 2.3.12, 2.3.14, and in other places.

• GVM represents all data as a set of cells (GVM) (see 2.3.14). Each cell contains up to 128 bytes of data and up to 4 references to other cells. As a consequence of the "package of cells" philosophy (see 2.2.14), this allows GVM to work with all data related to the Gold Blockchain, including blocks and the global state of the blockchain, if necessary.

• GVM can work with values of arbitrary types of algebraic data, represented as trees or directed acyclic graphs of GVM cells. However, it is agnostic to the existence of algebraic data types; it just works with cells.

• GVM has built-in support for all hash maps.

• GVM is a stack-based computer. Its stack stores either 64-bit integers or a cell.

Recommendations.

• Supports 64-bit, 128-bit, and 256-bit arithmetic. All n-bit arithmetic operations are performed in three variants: for unsigned integers, for signed integers, and for integers modulo 2 N (no automatic overflow checks in the latter case).

• GVM has unsigned and signed integer conversions from n-bit to m-bit, for all 0 ≤ m, n ≤ 256, with overflow checks.

• All arithmetic operations are carried out by the overflow checking by default, greatly simplifying the development of smart contracts.

• GVM has "multiply-then-shift" and "shift-then-divide" arithmetic operations with intermediate values calculated in a larger integer type; this simplifies the implementation of fixed-point arithmetic.

• GVM offers support for bit strings and byte strings.

• Support for 256-bit elliptic curve cryptography (ECC) for some predefined curves, including Curve25519.

• Support for Weyl pairing on some elliptic curves, useful for fast implementation of zk-SNARKs, is also present.

• Support for popular hash functions, including sha256, is present.

• GVM can work with Merkle proofs (see 5.1.9).

* GVM offers support for "large" or "global" smart contracts. Such smart contracts should be aware of segmentation. Regular (local) smart contracts can be segment-agnostic.

• GVM supports closures.

• "Infinite halogen-free G-machine" [13] can be easily implemented inside the GVM. Several high-level languages can be developed for GVM, in addition to"GVM assembly". All of these languages will have static types and will support algebraic data types. We assume the following possibilities:

• Java-like imperative language with each smart contract resembling a separate class.

• lazy functional language (think of Haskell).

• Desiring a functional language (think ML).

2.1.21. Configurable parameters. An important feature of the Gold Blockchain is that many of its parameters are configurable. This means that they are part of the masterchain main chain and can be changed by some special offers /votes / to the masterchain state, without any need for hard forks. Changing such parameters will require the collection of two-thirds of the validators ' votes and more than half of the votes of all other participants who would like to participate in the voting process in favor of this proposal.

2.2. Global state of the Shardchain segment chain. The "Cell Package" philosophy. Now we are ready to describe the global state of the Gold Blockchain or the smallest of the shardchain chain segments of the main workchain working chain. We start with a "high-level" or "logical" description, which says that the global state is a value of the algebraic type of the Shardchain structure.

2.2.1. The state of the Shardchain as a set of account states. According to the Infinite Sharding Paradigm (see 2.1.2), any shardchain is simply a (temporary) set of virtual "account chains" containing each exactly one account. This means that, in essence, the global state of the shardchain should be a hash map

ShardchainState: = (Account → AccountState) (23)

where all account_ids displayed as indexes of this hash map must start with prefix s if we are discussing the state of the segment (w, s) (see 2.1.8). In practice, we may need to split the AccountState into several parts (for example, keep a separate queue of account output messages to simplify its verification by neighboring shardchains), and have multiple hash maps (account → Part of the Account State_i) inside the Shardchain structure. We could also add a small number of "global" or "integral" parameters to the Shardchain structures (for example, the total balance of all accounts belonging to this segment, or the total number of messages in all output queues). However, (23) is a good first approximation of what the global shardchain state looks like, at least in terms of "logical" ("high-level"). A formal description of the algebraic types AccountState and ShardchainState can be made using the TL schema, which should be provided elsewhere.

2.2.2. Splitting and merging shardchain states. Note that the Infinite shardchain State Description Segmentation Paradigm (23) shows how this state should be handled when splitting or merging segments. In fact, these state transformations turn out to be very simple hash map operations.

2.2.3. Account status. The (virtual) state of an account is simply the state of a single account, described by the Account State type. It usually has all or some of the fields, depending on the specific constructor used.

2.2.4. Global working state of the workchain. Similarly (23), we can determine the global state of the workchain by the same formula, but with account_id - any values, not just those that belong to a single segment. The remarks made in 2.5.1 apply in this case as well: we can split this hash map into multiple hash maps and we might want to add some "integral" parameters, such as the total balance. In essence, the global working state of the workchain should be set to the same type of Shardchain state as the shardchain state, because this is the state of the shardchain we would get if all the existing segments of this working chain of the workchain suddenly merged into one.

2.2.5. Low-level perspective: "cell package". There is a "low-level" description of the state of the shardchain account or network that complements the "high-level" description above. This description is very important because it turns out to be quite versatile, providing a common framework for representing, storing, serializing, and transmitting over the network almost all of the data used by the Gold Blockchain (blocks, shardchain states, storage smart contracts, Merkle proofs, etc.). At the same time, such a universal "low-level" description, clear and implemented, allows us to focus our attention only on the "high level". Recall that GVM represents values of arbitrary algebraic types (including, for example, ShardchainState (23)) using a GVM tree of cells, or cells for short. Any such cell consists of two descriptor bytes defining their specific flags and values 0 ≤ b ≤ 128, the number of raw bytes, and 0 ≤ c ≤ 4, the number of references to other cells. This is followed by b raw bytes and c cell references.¹⁷ The exact format of cell references depends on the implementation and whether the cell is in RAM, on disk, in a network packet, in a block, and so on. A useful abstract model is to imagine that all cells are stored in address memory, the address of the cell being equal to its (sha256) hash.

Recall that the hash (Merkle) of a cell is calculated exactly by replacing references to its child cells with their (recursively calculated) hashes and hashing the resulting byte string. Thus, if we use cell hashes to refer to cells (for example, inside the description of other cells), the system is somewhat simplified and the hash of the cell begins to match the hash of the byte string representing it. Now we can see that any object represented by GVM, the global shardchain enabled state, can be represented as a "cell package" - a set of cells along with a" root " reference to one of them (for example, using a hash). Duplicate cells are removed from this description (a "cell package" is a set of cells, not a multiset of cells), so the abstract tree representation can actually become a directed acyclic graph (dag). You can even store this state on disk in a B-or B + tree containing all (possibly with some additional data, such as the height of the subtree or the reference count) indexed by the hash of the cell. However, a naive implementation of this idea will lead to the decomposition of the state of a single smart contract among the deleted parts of the disk file, which we would prefer to avoid.¹⁸ Now we will explain in detail how almost all the objects used by the Gold Blockchain can be represented as "cell packages", which demonstrates the versatility of this approach.

17 It can be shown that if Merkle proofs are needed for all the data stored in the cell tree, cells with b + ch ≈ 2 (h + r) should be used equally often to minimize the average Merkle proof size, where h = 32 is the hash size in bytes and r ≈ 4 is the "byte size" of the cell reference. In other words, the cell must contain either two references and a few raw bytes, or one reference and about 36 raw bytes, or no reference at all to the 72 raw bytes.

18 The best implementation is to store the state of the smart contract as a serialized string if it is small, or in a separate B-tree if it is large; the top-level structure representing the state of the blockchain will be a B-tree whose leaves are resolved and contain references to other B-trees.

2.2.6.A Shardchain block, as a "cell package". The shardchain block itself can also be described by an algebraic type and is stored as a "bag of cells". Then a naive binary representation of the block can be obtained by simply combining the strings of bytes representing each of the cells in the "bag of cells", in any order. This representation can be improved and optimized, for example, by providing a list of offsets of all cells at the beginning of the block and replacing hash references to other cells with 32-bit indexes in this list, whenever possible. However, it should be assumed that the block is essentially a "package of cells", and all other technical details are optimization and implementation issues.

2.2.7. Updating the object as a "cell package". Imagine that we have an old version of some object represented as a "cell package" and that we want a representation of a new version of the same object, presumably not too different from the previous one. You can simply represent the new state as another "cell package" with its own root and remove all cells originating from the old version from it. The remaining "cell pack" is an update of the object. More precisely, there is an old version of this object, the update can calculate the new version, merge the two cell packages, and remove the old root (reducing its reference count and highlighting it if the reference count becomes zero).

2.2.8. Updating the account status. Updates to the account state or the global state of the shardchain or any hashmap storage can be represented using the idea described in 2.2.7. This means that when we get a new shardchain block (which is a "cell package"), we interpret this" cell package "not only by itself, but combine it first with a" cell package " representing the previous state of the shardchain. In this sense, each block can "contain" the entire state of the blockchain.

2.2.9. Updating the block. Recall that the block itself is a "cell package", so if you need to edit a block, you can also define a" block", update as a cell package interpreted in the presence of a" cell package", which is a previous version of this block. This is an example of the idea of "vertical blocks" discussed in 2.1.17.

2.2.10. Merkle's proof as a "package of cells". Please note that the (generalized) Merkle's proof, for example, stating that x [i] = y, starting with the known Hash value (x) = h, can also be represented as a "cell package". Namely, you just need to provide a subset of cells corresponding to the path from the root x: Hashmap (n, X) to its desired leaf with the index i: 2ⁿ and the value y : X. References to the descendants of these cells that do not lie in this path will remain "unresolved" in this proof presented by the hashes cell. You can also provide a simultaneous proof of Merke, say, x [i] = y and x [i¹] = y¹, by including in the" cell package " the cells lying on the union of two paths from the root of x to the leaves corresponding to the indices i and i¹.

2.2.11. Merkle proofs as query responses from full nodes. Essentially, a full node with a full copy of the shardchain state (or account) can provide a Merkle proof on demand of a light node (such as a network node running a light version of the Gold Blockchain client), allowing the recipient to perform simple queries without external assistance, using only the cells provided in this Merkle proof. A light node can send its queries in serialized format to a full node and get correct responses using the Merkle Proof, since the query must be able to compute the responses using only the cells included in the Merkle proof. This Merkle proof would consist simply of a "cell packet" containing only those cells belonging to the segment state that were accessed by the full node when executing the light node query. This approach can be used, in particular, to perform" requests for obtaining " smart contracts.

2.2.12. Extended update or state update using Merkle proof validity. Recall (see 2.2.7) that we can describe changes to an object from the old x: X to the new x ¹ : X by means of "update", which is simply a "batch of cells" containing those cells that are in the subtree representing the new x ¹ , but not in the subtree representing the old x, the recipient is assumed to have a copy of the old x and all its cells. However, if the recipient does not have a complete copy of x, but only knows it (Merkle) hash h = Hash (x), he will not be able to check the validity of the update (all dangling cell references in the update refer to cells present in the tree x) ... We would like to have "verifiable" updates, supplemented by Merkle's proof of the existence of all the mentioned cells in the old state. Then anyone who only knows h = Hash (x) can check if the update was correct and calculate the new h ¹ = Hash (x ¹ ). Our Merkle proofs are "packs of cells" (see 2.2.10), someone could build an extended update such as "packs of cells" containing the old root x, some of its descendants along with paths from the root x to their new root x ¹ and all of its descendants that are not part of x.

2.2.13. Account status updates in the shardchain block. In particular, account state updates in a shardchain block must be padded, as discussed in 2.2.12. Otherwise, someone might commit a block containing an invalid state update referring to a cell missing from the old state; proving the invalidity of such a block would be problematic (how does the challenger prove that the cell is not part of the previous state?). Now, if all the state updates included in the block are padded, their validity is easily checked and their invalidity is also easily revealed as a violation of the recursive defining property of the (generalized) Merkle hashes.

2.2.14. The "Cell Package" philosophy. The previous considerations show that everything we need to store or transfer, either to the Gold Blockchain or to the network, is represented as a "cell packet". This is an important part of the Gold Blockchain design philosophy. Once the "cell package" and some "low-level " serializations of the" cell package " are defined, you can simply define everything (block format, shardchain and account status, and so on) a high-level abstract (dependent) algebraic data type. The unifying effect of the "cell package" philosophy greatly simplifies the implementation of seemingly unrelated services; see 5.1.9 for an example with payment channels.

2.2.15. The "headers" block for the Gold Blockchain. Usually, a block in the blockchain starts with a small header containing the hash of the previous block, the time of its creation, the Merkle hash of the tree of all transactions in the block, and so on. Then the block hash is defined as the hash of this small block header. Since the block header ultimately depends on all the data included in the block, you cannot change the block without changing its hash. In the "package of cells" approach used by Gold Blockchain blocks, there is no assigned block header. Instead, the block hash is defined as the (Merkle) hash of the root cell of the block. Therefore, the top (root) cell of the block can be considered a small "header" of this block. However, the root cell may not contain all the data normally expected from such a header. Basically, you need the header to contain some fields defined in the block data type. Typically, these fields will be contained in multiple cells, including the root. These are the cells that together form a "Merkle Proof" for the values of the fields in question. One could insist that the block contains these "header cells" at the very beginning, before the other cells. Then you will need to load only the first few bytes of the block serialization to get all the "header cells" and examine all the expected fields.

The Gold Blockchain ultimately consists of shardchain and masterchain blocks. These blocks need to be created, validated, and distributed across networks to all stakeholders in order for the system to function smoothly and correctly.

2.3.1. Validators. New blocks are created and validated by special nodes called validators. Essentially, any node wishing to become a validator can become one if it can make a sufficiently large bid (in AUR coins, i.e. grams, see Appendix A) to the masterchain. Validators receive some "rewards" for good work, namely for transactions, storage, and gas fees from all transactions (messages) made in newly created blocks and some newly minted coins, reflecting the" gratitude " of the entire community to the validators for keeping the Gold Blockchain running. This revenue is distributed among all participating validators in proportion to their bids. However, being a validator is a high responsibility. If a validator signs an invalid block, it can be penalized by losing part or all of its share and by being temporarily or permanently excluded from the validator set. If the validator does not participate in the creation of the block, it does not receive the share of the reward associated with this block. If the validator refrains from creating new blocks for a long time, it may lose some of its share and be suspended or permanently excluded from the set of validators. All this means that the validator does not get their money "for nothing". In fact, it should monitor the state of all or some segments (each validator is responsible for checking and creating new blocks in a certain subset of shardchains), perform all the calculations requested by smart contracts in these segments, receive updates about other segments, etc. This activity requires significant disk space, computing power, and network bandwidth.

2.3.2. Validators instead of miners. Recall that the Gold Blockchain uses the "Proof of Stake" approach, instead of the accepted "Proof of Work" approach for Bitcoin, the current version of Ethereum and most other cryptocurrencies. This means that you can't "create" a new block by presenting some proof of work (calculating a lot of useless hashes) and get new coins as a result. Instead, you need to become a validator, directing your computing resources to store and process requests and data on the Blockchain. You need to be a validator for new coins. In this respect, validators are the new miners. However, there are other ways to earn coins besides being a validator.

2.3.3. Nominators and "mining pools". To become a validator, you usually need to buy and install several high-performance servers, as well as provide them with a good Internet connection. This is not as expensive as the ASIC hardware that is currently required for Bitcoin mining. However, it is definitely not possible to create new Gold coins on a home computer, let alone a smartphone. In the Bitcoin, Ethereum, and other cryptocurrency Proof-of-Work algorithm communities, there is the concept of mining pools, where many nodes with insufficient computing power to create new blocks on their own combine their efforts and share the reward afterwards.

The corresponding concept in the world of "Proof of Share" is the concept of the nominator. Essentially, it is a node providing its money to help the validator increase its bid (share); the validator then distributes the appropriate share of its reward (or some pre-agreed share, such as 50%) to the nominee. The nominee can participate in the" block mining " and receive a reward in proportion to the amount of money that he wants to contribute for these purposes. It receives only a fraction of the corresponding share of the validator's reward, since it provides only "capital" and does not need to purchase computing power, storage, and network bandwidth. However, if the validator loses its share due to misconduct, the nominator also loses its share. In this sense, the nominee shares the risk.

He must choose the designated validator wisely, otherwise he may lose money. In this sense, nominators make an informed decision and "vote" for some validators for their funds. On the other hand, this system of promotion or crediting allows you to become a validator without investing a large amount of money in (AUR tokens). In other words, it prevents the storage of large amounts of AUR from monopolizing the supply of validators.

2.3.4. Fishermen: get paid by pointing out the mistakes of others. Another way to get some rewards without being a validator is to become a fisherman. Essentially, any node can become a fisherman by making a small deposit in the masterchain. Then it can use a special transaction masterchain to publish (Merkle) proof of the invalidity of some (usually shardchain) blocks previously signed and published by validators. If the other validators agree with this proof of invalidity, the guilty validators are punished (losing part of their share), and the fisherman receives some reward (part of the coins confiscated from the infringing validator). Correcting invalid masterchain blocks may involve creating "vertical" blocks on top of previously committed masterchain blocks (see 2.1.17); there is no need to create a fork of the masterchain.

Usually a fisherman should become a full node for at least some shardchains and spend some computing resources running some smart contract code. While a fisherman does not need to have a lot of computing power as a validator, we believe that a natural candidate to become a fisherman is a future validator ready to recycle new blocks that has not yet been selected as a validator (for example, due to failure to contribute a large enough share).

2.3.5. Sorter: getting money by offering new blocks for validators. Another way to get some rewards without being a validator is with a sorter. This is the node that prepares and offers the validator new shardchain block candidates, supplemented (mapped) with data taken from the state of this chain and from other (usually neighboring) shardchains, along with the corresponding Merkle proofs. (This is necessary, for example, when some messages need to be sent from neighboring shardchains.) The validator can then easily validate the proposed block candidate for validity, without having to load the full state of this or another shardchains segment. Since the validator must submit new (matched) candidates for the block, receive some ("mining") rewards, it makes sense to pay part of the reward to the sorter who wants to provide suitable candidates for the block. In this case, the validator can free itself from the need to monitor the state of neighboring shardchains by passing it to the sorter. However, we expect that during the initial installation of the system, there will be no separate assigned sorters, since all validators will be able to act as sorters for themselves.

2.3.6. Collators (sorters) or validators: receiving money to enable the user of the transaction. Users can open micropayment channels to some sorters or validators and pay out small amounts of coins in exchange for including their transaction in the shardchain.

2.3.7. Election of the global validator. A "global" set of validators is elected once a month (in fact, every 2 ¹⁹ masterchain blocks). This set is determined and publicly known one month in advance. To become a validator, a node has to transfer some AUR tokens to the masterchain masterchain, and then send them to a special smart contract as a bid offer s. The other parameter sent along with the rate is l ≥ 1, the maximum checking load that this node is willing to accept the relatively minimum possible. There is also a global upper bound (another configurable parameter) L by l, equal to, say, 10. A global set of validators is then selected by this smart contract, simply by selecting up to T candidates with maximum inferred bids and publishing their identity. Initially, the total number of validators is T = 100; we expect it to grow to 1000 as the load increases. This is a configurable parameter (see 2.1.21). The actual share of each validator is calculated as follows: if the top T of the proposed rate is s ₁ ≥ s ₂ ≥ ≥ s _T , the actual share is i -th validator is equal to the set in s ^I _i : = min (s _i , l _i S _T ). So s ^I _i / s ^I _T ≤ l _i , so The i-th validator will not receive more than l _i ≤ L times the load of the weakest validator (because the load is ultimately proportional to the rate).

The selected validators can then withdraw the unused portion of their share, s_i - s^I_i. Non-admitted candidates for the validators can remove all of their shares. Each validator publishes a public key signature, not necessarily equal to the public key of the account to which the payment was made^.19 Validators ' bids are frozen until the end of the period for which they were elected, and for another month, in case of new disputes (i.e. an invalid block signed by one of these validators is found). After that, the bet is returned, along with the validator's share of the minted coins and the commission from transactions processed during this time.

19 It makes sense to generate and use a new key pair for each validator selection.

2.3.8. Election of "target groups" of the validator. The entire global set of validators (where each validator is considered to be present with a cardinality equal to its share, otherwise the validator might be tempted to accept multiple credentials and split their share among them) is only used to validate new masterchain blocks. The shardchain segment blocks are checked only by specially selected subsets of validators taken from the global set of validators selected as described in 2.3.7. These “subsets” of the validator or “task group” defined for each segment are changed every hour (in fact, every 2 ¹⁰ masterchain blocks) and they are known one hour in advance, so that each validator knows which segments he will need to check and can prepare for this (for example, by loading the missing shardchain data). The algorithm used to select groups of scan tasks for each segment (w, s) is deterministic pseudo-random. It uses embedded pseudo-random numbers for validators on each masterchain block (generated by consensus using threshold signatures) to generate a random seed, and then calculates, for example, Hash (Code (w). Code (s). Validator_id.rand_seed) for each validator. Then the validators are sorted by the value of this hash and the first few are selected to have at least 20 / T of the total number of validator bets, but at least 5 validators. This choice can be made using a dedicated smart contract. In such a case, the selection algorithm could easily be updated without the hard forks of the voting mechanism mentioned in 2.1.21. All other "constants" are mentioned so far (for example, 2 ¹⁹ , 2 ¹⁰ , T, 20, and 5) and are also configurable parameters.

2.3.9. Alternating priorities for each task group. There is a certain "priority" order imposed on the members of the segment task group, depending on the hash of the previous masterchain block and the sequence of block numbers (shardchain). This order is determined by generating and sorting some hashes as described above. When a new shardchain block needs to be created, the validator task group segment selected to create that block is usually the first one, with respect to this rotating "priority" order. If it fails to create a block, the second or third validator can do so. Essentially, they can all propose their own candidate block, but the candidate proposed by the validator with the highest priority must win as a result of the consensus Byzantine Rejection of Tolerance, (BFT) protocol.

2.3.10. Distribution of shardchain block candidates. Since shardchain's membership in a task group is known an hour in advance, their members can use this time to create a dedicated "multicast validator validation overlay network" using the common Gold network mechanisms (see 3.2) When a new shardchain block needs to be created-usually one or two seconds after the most recent masterchain block has been distributed-everyone knows who has the highest priority to generate the next block (see 2.3.9). This validator will create a candidate for the new sorted block either by itself or by using a collator (see 2.3.5). The validator must check (confirm) this (especially if it was prepared by some collator) and sign it with your private key. The block candidate is then propagated to the rest of the task group using a pre-set multicast overlay network (the task group creates its own overlay network as described in 3.2, and then uses a version of the described multicast streaming protocol (see 3.2.15) to propagate block candidates). The BFT algorithm does this using a Byzantine multicast distribution protocol, similar to the one used in Honey Badger BFT [11]: encoding the candidate block by (N, 2N/3) - random code, send 1/N of the received data directly to each member of the group, and expect to multicast directly their portion of the data to all other members of the group.

However, a faster and easier way to do this (see also 3.2.15) is to split the block candidate into a sequence of signed one-kilobyte blocks ("fragments") that complement their sequence with a Reed-Solomon or fountain of code (e.g., RaptorQ code [9] [14]) and start transmitting the fragments to neighbors in a "multicast grid" (i.e., an overlay network), waiting for them to propagate these fragments further. As soon as the validator receives enough fragments to restore the block candidate, it signs the confirmation receipt and distributes it through its neighbors throughout the group. Then its neighbors stop sending it new fragments, but can continue to send (original) signatures of these fragments, considering that this node can generate subsequent fragments itself, applying Reed-Solomon or fountain code (having all the necessary data), combines them with signatures and distributes it to neighbors that are not ready yet. If the "multicast grid" (overlay network) remains connected after all the "bad" nodes are removed (recall that up to one-third of the nodes are allowed to be bad by the Byzantine variant-behave arbitrarily maliciously), this algorithm will propagate the block candidate as quickly as possible. Not only can a designated high-priority block creator block a candidate for the entire group. The second and third priority validator can start multicasting their block candidates either immediately or after refusing to receive the block candidate from the top priority validator. However, usually only the candidate block with the highest priority will be signed by all (in fact, at least two-thirds of the task group) validators, as committed by the new shardchain block.

2.3.11. Checking candidates for the block. After the validator receives the block candidate and the signature of its initiating validator, the receiving validator verifies the validity of this block candidate, performs all transactions in it, and verifies that the result matches the previously approved one. All messages imported from other blocks must be supported with suitable Merkle proofs in the matched data, otherwise the candidate block is considered invalid (if the proof of this is committed against the masterchain main chain, validators who have already signed this candidate block may be penalized). On the other hand, if the block candidate found is valid, the receiving validator signs it and distributes its signature to other validators in groups, either via the "multicast network" or the direct Message network. We would like to emphasize that the validator does not need access to the state of this or neighboring segments to verify the validity of the candidate (mapped).²⁰ This allows you to check the correctness quickly (without disk access), facilitates calculations, and reduces the load on validators (especially if they are willing to accept the services of external collators (sorters) to create candidates for the block).

20 A possible exception is the state of the output queues of adjacent segments required to meet the message order requirements described in 2.4.21, since the size of the Merkle proofs can become prohibitively large in this case.

2.3.12. Election of the next candidate of the block. Once a block candidate collects at least two-thirds (at the rate of) of the validator validity signatures in the target group, he can be assigned to the next shardchain block. The BFT protocol is run to reach consensus on the selected block candidate (there may be multiple proposals), with all "good" validators preferring the block candidate with the highest priority for that round. As a result, when launching this protocol, the block is supplemented with the signatures of at least two-thirds of the validators (at the rate). These signatures indicate not only the validity of the block in question, but also its election to the BFT protocol. After that, the block (without mapped data) is combined with these signatures, serialized in a deterministic way and distributed across networks to all interested parties.

2.3.13. Validators must keep the blocks they signed. During their membership in the target group and at least one hour (rather 2 ¹⁰ blocks), validators are expected to store the blocks they signed and committed. Validators may be penalized for failing to provide a signed block to others.

2.3.14. Distribution of headers and signatures of new shardchain blocks for all validators. Validators distribute the headers and signatures of newly created shardchain blocks to a global set of validators, using a multicast network similar to the one created for each task group.

2.3.15. Generating new masterchain blocks. A new masterchain block can be generated after new shardchain blocks have been created. The procedure is essentially the same as for shardchain blocks (see 2.3.12), with the difference that all validators (or at least two-thirds of them) must participate in this process. Since the headers and signatures of the new shardchain blocks are distributed to all validators, the hashes of the newest blocks in each shardchain can and should be included in the new masterchain block. Once these hashes are passed to the masterchain, observers and other segments can view the new shardchain blocks as perfect and immutable (see 2.1.13).

2.3.16. Validators must maintain the masterchain state. Notably, the difference between masterchains and segments is that all validators are expected to track the state of the masterchains without relying on mapped data. This is important because knowledge of the validator's target groups is inferred from the state of the masterchain main chain.

2.3.17. Shardchain blocks are generated and distributed in parallel. Usually, each validator is a member of several shardchain task groups; their number (hence the load on the validator) is approximately proportional to the validator's share. This means that the validator runs multiple instances of the new shardchain block generation protocol in parallel.

2.3.18. Mitigation of block blocking attacks. A common set of validators inserts a new hash of the segment block into the masterchain after seeing its header and signatures, however, there is a small chance that the validators who generated this block will collude and try to avoid publishing the new block completely. This will cause the validators of the neighboring segments to be unable to create new blocks, because they must know at least the output message queue of the new block once its hash has been committed to the masterchain. To mitigate this, the new block must collect signatures from some other validators (for example, two-thirds of the target groups of neighboring segments), indicating that these validators have copies of this block and are ready to send them to any other validators, if necessary. Only after these signatures are submitted will the hash of the new block be included in the masterchain.

2.3.19. Masterchain blocks are generated later than shardchain blocks. Masterchain blocks are generated approximately once every five seconds, just like shardchain blocks. However, the generation of new blocks in all segments is performed essentially at the same time (usually the release of a new masterchain block is triggered), the generation of new masterchain blocks is deliberately delayed to enable hashing of newly created segment blocks in the masterchain.

2.3.20. Slow validators get lower rewards. If the validator is "slow", it may not approve new block candidates, and two-thirds of the signatures needed to commit a new block can be collected without its participation. In this case, he will receive a smaller share of the reward associated with this block. This provides an incentive for validators to optimize their hardware, software, and network connection to process user transactions as quickly as possible. However, if the validator cannot sign a block before it is committed, its signature can be included in one of the following blocks, and then a portion of the reward (exponentially decreasing depending on how many blocks were created, for example 0.9 ^{To if the validator creates k blocks later) will be issued to this validator.}

2.3.21. "Depth" of validator signatures. Usually, when a validator signs a block, the signature only indicates the relative validity of the block: this block is valid, provided that all previous blocks in this and other segments are valid. The validator may be punished for the invalidation of the data recorded in the previous blocks. However, the block validator signature has an integer parameter called "depth". If it is non-zero, it means that the validator asserts (relatively) the validity of the specified number of previous blocks. This is a way for "slow" or "temporarily disabled" validators to catch up and sign some blocks that were committed without their signature. Then, some part of the block reward will be given to them as before (see 2.3.20).

2.3.22. Validators are responsible for the relative validity of signed segment blocks; absolute validity follows. We would like to emphasize once again that the validator signature on the Shardchain B block only indicates the relative validity of this block (or perhaps d of the previous blocks as well, if the signature has a "depth" of d, see 2.6.21; but this does not affect the following discussion). In other words, the validator states that the next state s^I of the segment is obtained from the previous state s by applying the block evaluation function ev_block described in 2.2.6:

S^I = ev_block (B) (s) (24)

Thus, the validator who signed block B cannot be penalized if the original state turns out to be "incorrect" (for example, due to the invalidity of one of the previous blocks). The "fisherman" (see 2.3.4) must declare only if he finds a block that is relatively invalid. The PoS system as a whole tends to make each block relatively valid, rather than recursively (or absolutely) valid. Note, however, that if all the blocks in the blockchain are relatively valid, then all of them and the blockchain as a whole are absolutely true; this statement is easily shown using mathematical induction over the length of the blockchain. Thus, easily verifiable statements of the relative fairness of blocks together demonstrate a much stronger absolute validity of the entire blockchain. Note that by signing block B, the validator asserts that the block is valid given the original state of s (i.e. the result (24) is not a value of ⊥ indicating that the next state cannot be calculated). Thus, validators must perform minimal formal checks of the cells of the initial state that was accessed during the evaluation (24). For example, imagine that a cell must contain the original account balance available from a transaction committed to the block in order to have zero raw bytes instead of the expected 8 or 16. Then the original balance simply cannot be retrieved from the cell, and an "unhandled exception" occurs when trying to process the block. In this case, the validator should not sign such a block under penalty of punishment.

2.3.23. The signing of the masterchain blocks. The situation with masterchain blocks is somewhat different: by signing a masterchain block, the validator asserts not only its relative validity, but also the relative validity of all previous blocks up to the very first block, when this validator assumed responsibility (but no further).

2.3.24. The total number of validators. The upper limit T for the total number of validators to be elected (see 2.3.7) cannot be more than a few hundred or thousands in the system described so far, because validators are expected to participate in the BFT consensus protocol. for the creation of each new block of the masterchain and it is unclear whether such protocols are scalable to thousands of participants. More importantly, blocks must collect signatures of at least two-thirds of all validators (at a rate) and these signatures must be included in a new block (otherwise, all other nodes in the system will have no reason to trust new blocks without checking it on their own) ... Let's say more, thousands of validator signatures must be included in each block of the master chain, this will mean more data in each block of the master chain, which will be stored by all full nodes and propagated through the network, and more computing power is needed to verify these signatures (in a PoS system, for full node does not need to independently verify the blocks, but it is necessary to verify the signatures of the validators). While the T limit per thousand validators seems more than sufficient for the first phase of a TON Blockchain deployment, provision must be made for future growth when the total number of shardchains is so large that a few hundred validators will not be enough to handle all of them. To do this, we introduce an additional configurable parameter T ^I ≤ T (initially equal to T) and only the upper T ^I of the selected validators (by rate) is expected to create and sign new blocks masterchain.

2.3.25. Decentralization of the system. One would suspect that the Proof-of-Stake algorithm of a system such as the TON Blockchain, relying on T ≈ 1000 validators to create all shardchain and masterchain blocks, is bound to become “too centralized”, unlike conventional Proof-of-Work blockchains such like Bitcoin or Ethereum, where everyone (in principle) could create a new block, without an explicit upper limit on the total number of miners. However, popular Proof of Work blockchains such as Bitcoin and Ethereum currently require enormous computing power (high "hash rate") in order to create new blocks with an unrelenting success rate. Thus, the creation of new blocks is usually concentrated in the hands of a few large players, who invest huge sums of money in data centers filled with custom hardware optimized for mining; in the hands of several large "mining pools", which concentrate and coordinate the efforts of large groups of people who by themselves cannot provide sufficient "hash-speed". Therefore, as of 2017, over 75% of new Ethereum or Bitcoin blocks are produced by less than ten miners. In fact, the two largest Ethereum mining pools together produce over half of all new blocks! Obviously, such a system is much more centralized than another, relying on T ≈ 1000 nodes to produce new blocks.

It can also be noted that the investment required to become a Gold Blockchain Validator - the purchase of hardware (several high-performance servers) and a package (which can be easily assembled through a pool of nominees if necessary; cf. 2.3.3) - is much lower than it takes to become a successful offline Bitcoin or Ethereum cryptocurrency miner. In fact, the L parameter from 2.3.7 will force nominees not to join the largest mining pool (ie, the validator with the largest share), but rather look at smaller validators who are currently accepting funds from nominees or even create new ones. validators, since this will increase the share of s ^I _i / s _i validators, in addition, a nominal rate is also used, which stimulates large benefits from mining. Thus, the TON's proof-of-stake system actually encourages decentralization (the creation and use of validators) and punishes centralization.

2.3.26. Relative reliability of the block. The (relative) reliability of a block is the total percentage of all validators that signed that block. In other words, this is the amount of money that some participants will lose if this block turns out to be invalid. If we are talking about transferring transactions with a value lower than the reliability of the block, we can consider them sufficiently secure. In this sense, relative reliability is a measure of trust beyond the observer in a particular block. Note that we are talking about the relative reliability of a block, since this is a guarantee that the block is valid when the previous block and all the others are valid (see 2.3.22). The relative reliability of a block may increase after it is committed – for example, when adding late validator signatures (see 2.3.21). But on the other hand, if one of these validators loses part or all of its bid due to its misconduct related to some other blocks, the relative reliability of the block may decrease.

2.3.27. "Strengthening" the blockchain. It is important to provide incentives for validators to increase the relative reliability of blocks as much as possible. One way to do this is to allocate a small reward to validators for adding signatures to blocks of other shardchains segments. Even "potential" validators who have placed insufficient bids to qualify for the Top Bid Validators for inclusion in the global set of validators (see 2.3.7) can participate in this event (if they agree to keep their stake frozen instead of withdrawing it after a lost election). Such potential validators can double as "fishermen" (see 2.3.4): if they have to verify validity anyway, some blocks can also report invalid blocks and collect associated rewards.

2.3.28. Recursive reliability of the unit. You can also define the recursive reliability of a block as a minimum of its relative reliability, and the recursive reliability of all the blocks it belongs to (i.e., the masterchain block, the previous shardchain block, and some blocks of neighboring shardchains). In other words, if a block turns out to be invalid, either because it is invalid or because one of the blocks it depends on is invalid, then at least that amount of money will be lost by someone. If you are really unsure about trusting a particular transaction in a block, you need to calculate the recursive reliability of that block, not just the relative reliability. It doesn't make sense to go too far back when calculating recursive reliability, because if we look too far back, we'll see blocks signed by validators whose bids have already been unfrozen and withdrawn. In any case, we do not allow the validators to automatically revise blocks that are old (i.e. created more than two months ago, if the current values of the configurable parameters are used) and create forks starting from them or correct them using "vertical blockchains" (see 2.1.17), even if they turn out to be invalid. We assume that a period of two months provides ample opportunities for detecting and reporting any invalid blocks, so that if a block is not contested during this period, it is unlikely to be contested at all.

2.3.29. Corollary of the "Proof of proportion" for light nodes. An important consequence of the "Proof of Stake" approach used by Gold Blockchain is that the light node (software for working with a light client) for Gold Blockchain does not need to load the "headers" of all shardchain or even masterchain blocks in order to be able to verify by itself the validity of the Merkle proofs provided to it by full nodes as responses to its requests. In fact, since the most recent hashes of shardchain blocks are included in masterchain blocks, a full node can easily provide Merkle proof that a given shardchain block is valid, starting with the known hash of the masterchain block. Next, the light node needs to know only the very first masterchain block (where the very first set of validators is declared), which (or at least its hash) can be embedded in the client software, only one masterchain block, approximately every month after that, when the newly selected validators are declared, since this block will be signed by the previous set of validators. Based on this, it can get the last few masterchain blocks, or at least their headers and validator signatures, and use them as a base to validate the Merkle proofs provided by the full nodes.

One of the most distinctive and unique features of the Gold Blockchain is its ability to automatically split the shardchain in two when the load becomes too high and connect them back together if the load decreases (see 2.1.10). We need to discuss this in detail because of its uniqueness and importance for the scalability of the entire project.

2.4.1. Segment (shard) configurations. Recall that at any given time, each workchain w is split into one or more segments (w, s) (see 2.1.8). These segments can be represented by the leaves of a binary binary tree, with a root (w,∅) and each non-leaf node (w, s) having related elements (w,s.0) and (w, s.1). Thus, each account belonging to the workchain w, one shard, and everyone who knows the current shardchain configuration can define a segment (w, s) containing the account_id: this is the only shard with the binary string s being the account_id prefix. A shard configuration is a binary shard tree or a collection of all active (w, s) for a given w (corresponding to the leaves of a binary tree segment), which is part of the masterchain state and is available to anyone who follows the masterchain masterchain.²¹

21 In fact, the segment configuration is completely determined by the last derivative of the masterchain block; this makes it easier to access the segment configuration.

2.4.2. The most recent configuration and state of the segments. Recall that the hashes of the most recent shardchain blocks are included in each masterchain block. These hashes are organized in a binary binary tree of segments (actually, collections of trees, one for each workchain). Thus, each masterchain block contains the most recent segment configurations.

2.4.3. The announcement and implementation of changes in the configuration of the segments.

The configuration of the segments can be changed in two ways: either the segment (w, s) can be divided into two segments (w, s.0) and (w, s.1), or the two "brothers" (w, s.0) and (w, s.1) can be combined into one segment (w, s). These block split / merge operations are declared (for example, 2⁶; this is a configurable parameter) in advance, first in the" headers " of the corresponding shardchain blocks, and then in the masterchain block that references these shardchain blocks. This pre-announcement is necessary for all stakeholders to prepare for the planned changes (for example, creating a multicast network overlay to distribute new blocks of newly created segments, as described in clause 3.2). The change is then committed, first in the (header) shardchain block (in the case of splitting and merging, the blocks of both segments must commit the changes), and then propagated to the masterchain block. Thus, the masterchain defines not only the most recent configuration segments before it is created, but also the next segment configurations.

2.4.4 Validator task groups for new segments. Recall that each segment, that is, each shardchain, is usually assigned a subset of validators (a task group) designed to create and validate new blocks in the corresponding shardchain (see 2.3.8). These target groups are selected for a certain period of time (approximately one hour) and are known in advance (also approximately one hour) and are unchanged during this period.²² However, the actual configuration of the segments may change during this period due to split and merge operations. You must assign task groups to the new segment creators. This is done as follows: Note that any active segment (w, s) will either be a descendant of some uniquely defined source segment (w, s¹), which means that s¹ is a prefix of s, or it will be the root of the subtree of the original segments (w, s¹), where s will be the prefix of each s¹. In the first case, we simply take the task group of the original shard (w, s¹) to double as the task group of the new segment (w, s). In the latter case, the task group of the new segment (w, s) will be the union of the groups of all the original segments(w, s¹) that are descendants of (w, s) in the segment tree. Thus, each active segment (w, s) is assigned a well-defined subset of validators (task group). When a shard splits, both descendants inherit an entire task group from the original shard. When two shards are merged, their task groups are also merged. Anyone who monitors the state of the masterchain can calculate the task group validator for each of the active segments.

22 If some validators are temporarily or permanently banned due to signing invalid blocks, they are automatically excluded from all task groups.

2.4.5. Restriction on split / merge operations during the period of responsibility of the original task groups. The new configuration of the segments will be taken into account, and the new allocated subsets of validators (task groups) will be automatically assigned to each segment. Before this happens, you need to impose a certain limit on split / merge operations; otherwise, the original task group can complete checking 2 ^k shardchains for a large k, at the same time if the original segment quickly splits into 2^k new segments. This is achieved by imposing restrictions on how far the active segment configuration is removed from the original segment configuration (used to select validator task groups at the moment). For example, one might require that the distance in the segment tree from the active segment (w, s) to the original segment (w, s¹) should not exceed 3 if s¹ is the predecessor of s (i.e. s¹ is the prefix of the binary string s) and should not exceed 2 if s¹ is the successor of s (i.e. s is a prefix of s¹). Otherwise, the split or merge operation is not allowed. Roughly speaking, a limit is imposed on the number of segment divisions (for example, three) or their combinations (for example, two) during the period of responsibility for a specific set of validator task groups. Once a segment has been created by merging or splitting, it cannot be changed for a certain period of time (a certain number of blocks).

2.4.6. Determining whether to separate operations. The split operation for the shardchain is initiated by certain formal conditions (for example, if for 64 consecutive shardchain blocks, the blocks are at least 90% full). These conditions are controlled by the shardchain task group. If they fail first flag "split provisioning" is included in the Header of the new shardchain block (and extends to the masterchain block by referring to this shardchain block.) Then, after a few blocks, the "split commit" flag is included in the shardchain block header (and propagated to the next masterchain block.)

2.4.7. Performing split operations. After enabling the "split commit" flag in block B of the shardchain (w, s), there can be no subsequent block B0 in this shardchain. Instead, two blocks B¹₀ and B¹₁ (w, s.0) and (w, s.1) will be created, referring to block B as their previous block (and both of them will indicate with a flag in the header that the segment was just split). The next masterchain block will contain the hashes of blocks B¹₀ and B¹₁ of the new segments; it is not allowed to contain the hash of the new block B¹ shardchain (w, s), because the "split commit" event is already committed in the previous masterchain block. Note that both new shardchains will be validated by the same validator as one old one, so they will automatically have a copy of their states. The state separation operation itself is quite simple in terms of the Infinite Segmentation Paradigm (see 2.2.2).

2.4.8. Determining the need for merge operations. The need for shard merge operations is also found under certain formal conditions (for example, if for 64 consecutive blocks, the sum of the sizes of two shardchains brothers ' blocks does not exceed 60% of the maximum block size). For these formal conditions, you should also consider the total amount of gas spent by these blocks and compare it to the current block gas limit, otherwise the blocks may be small because there are some intensive calculations that prevent more transactions from being included. These conditions are controlled by the validator target groups of both related segments (w, s. 0) and (w, s.1). Note that related segments are necessarily neighbors with respect to hypercube routing, so validators from the task group of any segment will have some control over the traces of the related segment. When these conditions are met, one of the validator subgroups can suggest to the other that they merge by sending a special message. They are then grouped into a temporary "joint task force", with a joint membership, able to run BFT consensus algorithms, distribute and block updates, block candidates if necessary. If they reach a consensus on the need and readiness of a merge, "merge prepare" flags are passed to the headers of some blocks of each shardchain, along with the signatures of at least two-thirds of the validators of the task groups of the related segment (and are distributed to the next masterchain blocks, so that everyone can prepare for the earliest reconfiguration). However, they continue to create separate shardchain blocks for some predefined number of blocks.

2.4.9. Performing merge operations. Once the validators from the merge of the two original target groups are ready to become validators for the merged shardchain (this may include state transfers from the related shardchain segment and state pooling operations), they commit a "merge commit" flag in the block headers of their shardchain (this event propagates to the next masterchain blocks) and stop creating new blocks in separate shardchains (after the merge commit flag appears, creating blocks in a separate segment is prohibited). Instead, a combined shardchain block is created (combining the two original task groups), referring to both of its " preceding blocks "in its"header". This is reflected in the next block of the masterchain masterchain, which will contain the hash of the newly created block of the combined shardchain. After that, the merged task group continues to create blocks in the merged shardchain.

The cornerstone in building Gold Digital network protocols is the Abstract Network Layer (datagram). This allows all nodes to accept certain "Network identifiers" represented by 256-bit "abstract network addresses" and messages (send datagrams to each other as a first step), using only these 256-bit network addresses to identify the sender and recipient. In particular, there is no need to worry about IPv4 or IPv6 addresses, UDP port numbers, etc.; they are hidden by the abstract network layer.

3.1.1. Abstract network addresses. An abstract network address, or abstract address, is a 256-bit integer, essentially equal to a 256-bit ECC public key. This public key can be generated arbitrarily, thus creating as many different network IDs as the node likes. However, you need to know the appropriate private key to receive (and decrypt) the message intended for such an address. In fact, the address is not a public key; instead, it is a 256-bit hash (Hash = sha256) of a serialized TL object (see 2.2.5), which can describe several types of public keys and addresses, depending on its constructor (four bytes first). In the simplest case, this serialized TL object consists only of a 4-byte magic number and a 256-bit elliptic curve cryptography (ECC) public key; in this case, the address will be equal to the hash of this 36-byte structure. However, you can use 2048-bit RSA keys or any other public key cryptography scheme instead. When a node learns the abstract address of another node, it must also receive its "preimage" (i.e. a serialized TL object whose hash is equal to an abstract address), otherwise it will not be able to encrypt and send datagrams to this address.

3.1.2. Lower-level networks. Implementation of the UDP. Of all the components of the Gold Network, one (the network layer of the abstract datagram) capable (unsatisfactory) to send a datagram to an abstract from one address to another. In principle, the Abstract Datagram Network Layer (ADNL) can be implemented by various existing network technologies. However, we are going to implement this over UDP on IPv4 / IPv6 networks (like the Internet or intranets), with an optional TCP protocol if UDP is not available.

3.1.3. The simplest case of ADNL over UDP. The simplest case of sending a datagram from an abstract sender address to any other abstract address (with a known prototype) can be implemented as follows. Assume that the sender somehow knows the IP address and UDP port of the recipient that the destination address of the recipient belongs to, and that both the recipient and the sender use abstract addresses derived from the 256-bit ECC public key. In this case, the sender simply increments the datagram, the ECC signature being sent (with the private key), and the source address (or a prototype of the source address if the recipient does not know it). The result is encrypted with the recipient's public key embedded in the UDP datagram and sent to the known IP address and port of the recipient. Since the first 256 bits of a UDP datagram contain an abstract address, the receiver can determine which private key is needed to decrypt the rest of the datagram. Only then is the sender's identity revealed.

3.1.4. A less secure path, with the sender's address in clear text. Sometimes, a secure scheme is not enough when the recipient and sender addresses are stored in plaintext in a UDP datagram; the sender's private address key and the recipient's public key are combined together using ECDH (the elliptic Diffie-Helman curve) to create a 256-bit shared secret that is used afterwards, along with a random 256-bit value included in the unencrypted form to get the AES keys used for encryption. Integrity can be provided, for example, by combining the hash of the original plaintext of the data into plaintext before encryption. The advantage of this approach is that if more than one datagram is expected to be exchanged between two addresses, the shared secret can only be computed once and then cached; then the slower elliptic curve operations will no longer be required to encrypt or decrypt the following datagrams.

3.1.5. Channels and channel IDs. In the simplest case, the first 256 bits of a UDP datagram containing an embedded Gold ADNL datagram will be equal to the recipient address. However, they usually make up the channel ID. There are different types of channels. Some of them are point-to-point; they are created by two parties who want to exchange a lot of data in the future and generate a shared secret by exchanging multiple packets encrypted as described in 3.1.3 or 3.1.4, by running a classical or elliptic Diffie-Hellman curve (if additional security is required), or just one, creating a random shared secret and sending it to the other party. After that, the channel ID is derived from the shared secret with some additional data (such as the sender and recipient addresses), for example, by hashing, and this ID is used as the first 256 bits of the UDP datagram containing the data encrypted with this shared secret.

3.1.6. The channel as the tunnel ID. In general, the "channel" or "channel ID" simply selects the way to handle the incoming UDP datagram known to the receiver. If the channel is an abstract destination address, the processing is performed as specified in 3.1.3 or 3.1.4; if the channel is the setup point-to-point channel discussed in 3.1.5, the processing consists of decrypting the datagram using a shared secret, as explained earlier. In particular, the channel ID may actually choose to "tunnel" when the immediate recipient simply sends the received message to someone else - the actual recipient or another proxy server. Some encryption or decryption steps (similar to "onion routing" [6] or even " garlic routing»³⁰), can be made along the path and a different channel ID can be used to re-encrypt the forwarded packets (for example, a peer channel can be used to forward the packet to the next recipient on the path). Thus, some support for "tunneling" and "proxying" - somewhat similar to what is provided by TOR or I²P projects - can be added at the Gold datagram network abstract layer level, without affecting the functionality of all high-level Gold Digital network protocols, which would be agnostic of such an addition. This feature is used by the Gold Proxy service (see 4.1.11).

30 https: //geti2p.net/en/docs/how/garlic-routing

3.1.7. Null channel and bootstrap problem. A Gold ADNL node will have some "neighbor table" containing information about other known nodes, such as their abstract addresses and their prefigures (i.e. public keys) and their IP addresses and UDP ports. It will then gradually expand this table, using information obtained from these known nodes as responses to special queries, and sometimes pruning obsolete records. However, when a Gold ADNL node is just starting up, it may happen that it does not know any other node and may only know the IP address and UDP port of the node, but not its abstract address. This happens, for example, if a light client cannot access any of the previously cached nodes, any nodes are hard-coded in the software and must prompt the user to enter the IP address or DNS domain of the node, which must be resolved via DNS. In this case, the node will send packets to a special node - the "zero channel". This does not require knowledge of the recipient's public data (but the message must contain the sender's ID and signature), so the message is transmitted without encryption. It should normally only be used to obtain the identity (perhaps a one-time identity created specifically for this purpose) of the recipient, and then start communicating in a more secure way. Once at least one node is known, it is easy to populate the "neighbor table" and "routing table" for more records, learning them from responses to special requests sent to already known nodes. Not all nodes are required to process datagrams sent to the null channel, but those used to load light clients should support this feature.

3.1.8. TCP-type stream protocol over ADNL. ADNL, being an unreliable (small size) datagram protocol based on 256-bit abstract addresses, can be used as the basis for more complex network protocols. You can build, for example, a TCP-like flow protocol using ADNL as an abstract IP replacement. However, most components of the Gold Digital project do not need such a flow protocol.

3.1.9. RLDP or reliable large datagram protocol over ADNL. A robust ADNL-based arbitrary-size datagram protocol, called RLDP, is used instead of a TCP-like protocol. This robust datagram protocol can be used to send RPC requests to remote hosts and receive responses from them (see 4.1.5).

In a multi-blockchain system like Gold Blockchain, even full nodes are usually interested in getting updates (i.e. new blocks), just about some shardchains. For this purpose, a special overlay (auxiliary) network should be built within the Gold Digital network, on top of the ADNL protocol discussed in 3.1, one for each shardchain. Therefore, you need to create arbitrary axial subnets that are open to any nodes that want to participate. These overlay networks will run ADNL-based special gossip protocols. In particular, these gossip protocols can be used to distribute (transmit) arbitrary data within such subnets.

3.2.1. The overlay network. An overlay (sub) network is simply a (virtual) network implemented inside some larger network. Usually, only some nodes of the wider network participate in the overlay subnet and only some "Links" between these nodes, physical or virtual, are part of the overlay subnet. Thus, if the spanning network is represented as a graph (possibly a complete graph in the case of a datagram network such as ADNL, where any node can easily exchange data with any other), the overlay subnet is a subgraph of that graph. In most cases, an overlay network is implemented using some protocol built on the network protocol of a larger network. It can use the same addresses as a larger network, or use custom addresses.

3.2.2. Overlay networks in Gold Digital. Overlay networks in Gold Digital are built on the ADNL protocol discussed in 3.1; they use 256-bit ADNL abstract addresses, like addresses in overlay networks. Each node usually chooses one of its abstract addresses to double its address in the network overlay. Unlike ADNL, Gold Digital overlay networks typically do not support sending datagrams to arbitrary other nodes. Instead, some "semi-permanent" links are established between some nodes (called "neighbors", in relation to the overlay network in question) and messages are usually sent over these links (that is, from a node to one of its neighbors). Thus, the Gold Digital overlay network is a (usually incomplete) subgraph within the (complete) graph of the ADNL network. Neighbor links in Gold Digital overlay networks can be implemented using dedicated ADNL peer channels (see 3.1.5). Each node in the overlay network maintains a list of neighbors (with respect to the overlay network) containing their abstract addresses (which they use to identify them in the overlay network) and some communication data (for example, the ADNL channel used to communicate with them).

3.2.3. Private and public overlay networks. Some overlay networks are public, which means that any node can join them at will. Other private ones that can only allow certain nodes (for example, those that can prove their IDs as validators.) Some private overlay networks may even be unknown to the "general public". Information about such overlay networks is provided only to certain trusted nodes; for example, it can be encrypted with a public key and only nodes that have a copy of the secret key will be able to decrypt this information.

3.2.4. Centralized overlay systems. Some overlay networks are centrally controlled by one or more nodes, or by the owner of a well-known public key. Others are decentralized, meaning there are no specific nodes responsible for them.

3.2.5. Connection to the overlay network. When a node wants to join the overlay network, it must first know its 256-bit network ID, normally equal to sha256 describe a network overlay-TL-serialized object (see 2.2.5), which can contain, for example, the Central authority of the overlay network (i.e., its public key and possibly her abstract address,³²), a string with the name of the overlay network segment ID Blockchain Gold, if this an overlay network is connected to that segment, and so on. Sometimes you can recover the overlay network description from the network ID by simply viewing it in Gold DHT. In other cases (for example, for private overlay networks), you need to get the network description along with the network ID.

32. Alternatively, the abstract address can be stored in the DHT, as described in 3.2.12.

3.2.6. Search for the overlay network. In addition to the node, you need to know the network ID and network description of the overlay network to join, and find at least one node that belongs to this network. This is also necessary for nodes that do not want to join the overlay network, but want to just communicate; for example, there may be a network overlay designed to collect and distribute transaction candidates for a particular shardchain and the client may want to connect to any node to offer a transaction. The method used to determine the location of the overlay network is defined in the description of this network. Sometimes (especially for private networks) you need to already know the member node to be able to join. In other cases, the abstract addresses of some nodes are contained in the network description. A more flexible approach is to specify in the network description only the central authority responsible for the network, abstract addresses will be available through the values of certain DHT keys signed by this central authority. Truly decentralized public overlay networks can use the "distributed torrent tracker" described in 3.2.10, which is also implemented with Gold DHT.

3.2.7. Search for more members of the overlay network. Creating a link. When one node of the overlay network is found, a special request can be made to that node, requesting a list of other members, such as neighbors of the requested node or its random selection. This allows a connection member to populate its "adjacency" or "neighbor list" in relation to the overlay network, by selecting some recently acquired network nodes and establishing connections with them (i.e., a dedicated point-to-point ADNL of channels, as specified in clause 3.2.2). After that, special messages are sent to all neighbors, indicating that the new member is ready to work in the overlay network. Neighbors include links to the new member in their neighbor lists.

3.2.8. Maintaining a list of neighbors. The overhead network node must update its list of neighbors from time to time. Some neighbors, or at least links (channels) to them, may stop responding; in this case, these links should be marked as "suspended", if some attempts to reconnect to such neighbors fail, the links should be destroyed. On the other hand, each node sometimes requests from a randomly selected neighbor its list of neighbors (or their random selection) and uses a partially updated list of its own neighbors, adding to it some of the recently discovered nodes, removing some of the old ones either randomly or depending on the time of their response and the datagram loss statistics.

3.2.9. Overlay network of a random subgraph. Thus, the overlay network becomes a random subgraph within the ADNL network. If the degree of each vertex is at least three (i.e., if each node is connected to three neighbors), this random graph is known to be connected with a probability almost equal to one. More precisely, the probability of a random graph with n vertices disconnected is exponentially small and this probability can be completely ignored if, say, n ≥ 20. (Of course, this does not apply in the case of a global network partition, where nodes on different sides of the partition have no way of knowing about each other.) But on the other hand, if n is less than 20, it would be sufficient for each vertex to have at least ten neighbors.

3.2.10. Gold Digital overlay networks are optimized for lower latency. Gold Digital overlay networks optimize the "random" network graph generated by the previous method as follows. Each node tries to keep at least three neighbors with minimal round-trip time, changing this list of "fast neighbors" very rarely. At the same time, it also has at least three other "slow neighbors" that are chosen completely randomly, so that the overlay network graph will always contain a random subgraph. This is necessary to ensure connectivity and prevent the superimposed network from splitting into multiple unrelated regional subnets. At least three "intermediate neighbors" that have an intermediate rounding time bounded by some constant (in fact, a function of the round-trip time of fast and slow neighbors) are also selected and stored. So the overlay network graph still retains enough randomness to connect, but is optimized for lower latency and higher throughput.

3.2.11. Gossip protocols in the overlay network. An overlay network is often used to run one of the so-called gossip protocols, a global target, allowing each node to communicate only with its neighbors. For example, there are gossip protocols for constructing an approximate list of all members of a (not too large) overlay network, or for calculating an estimate of the number of members of a (arbitrarily large) overlay network, using only a limited amount of memory on each node (see [15, 4.4.3] or [1] for details).

3.2.12. Overlay the network as a broadcast domain. The most important thing in a gossip protocol running on an overlay network is a broadcast protocol designed to propagate broadcast messages generated by any node in the network, or possibly one of the sender's assigned nodes, to all other nodes. In fact, there are several broadcast protocols optimized for different use cases. The simplest of them receive new broadcast messages and relay them to all neighbors who have not yet sent a copy of this message.

3.2.13. More complex broadcast protocols. Some applications may require more complex broadcast protocols. For example, to broadcast messages of significant size, it makes sense to send neighbors not the newly received message itself, but its hash (or a set of hashes of new messages). A neighbor can request the message itself after examining a previously unseen hash of the message to be transmitted, say, using the robust Large Datagram Protocol (RLDP) discussed in 3.1.9. Thus, a new message will be loaded from only one neighbor.

3.2.14. Checking the connection of the overlay network. Ability to connect an overlay network you can check whether there is a known node (for example, the "owner" or "creator" of the overlay network) that should be in this overlay network. Then the node in question simply translates in time to temporary short messages containing the current time, the sequence number, and its signature. Any other node can be sure that it is still connected to the superimposed network if it received such a broadcast not so long ago. This protocol can be extended to the case of multiple known nodes; for example, all of them will send such broadcasts and all other nodes will receive broadcasts, with more than half of the known nodes. In the case of an overlay network used to propagate new blocks (or just new block headers) to a particular shardchain, a good way for a node to check connectivity is to track the last received block. Since a block is usually generated every five seconds, if a new block is received for more than, say, thirty seconds, the node has probably been disconnected from the overlay network.

3.2.15. Streaming broadcast protocol. Finally, there is the streaming of the broadcast protocol for Gold Digital overlay networks, used, for example, to distribute candidate blocking among the validators of some shardchain ("task group" shardchain), which, of course, create a private overlay network for this. The same protocol can be used to distribute new shardchain blocks to all the full nodes of this shardchain. This protocol is already described in 2.3.10: a new (large) message broadcast is split into, say, N kilobit fragments; The sequence of these chunks is supplemented with M ≥ N chunks of data by means of an erasure code, such as Reed-Solomon or fountain code (for example, the RaptorQ code [9] [14]), and these M-chunks are transmitted to all neighbors in ascending order of the fragment number. Participating nodes collect these chunks until they can recover the original large message (you would need to successfully get at least N of the chunks to do this), and then instruct their neighbors to stop sending new chunks of the stream, because now these nodes can generate subsequent chunks by themselves, having a copy of the original message. Such nodes continue to generate subsequent chunks of the stream and send them to their neighbors, unless the neighbors in turn indicate that this is no longer necessary. This way, the node doesn't need to download a large message in its entirety before propagating it further. This minimizes broadcast latency, especially when combined with the optimizations described in 3.2.10.

3.2.16. Building new overlay networks based on existing ones. Sometimes you don't want to create an overhead network from scratch. Instead, one or more pre-existing overlay networks are known, and membership in the new overlay network is expected to overlap with the combined membership in these overlay networks. An important example occurs when the Gold shardchain is split into two parts or two segments are combined into one (see 2.4). In the first case, overlay networks must be built, used to propagate new blocks to full nodes for each of the new segments; However, each of these new network overlays is expected to be contained in the block distribution network (and make up approximately half of its members). In the second case, the overlay network for distributing new blocks of the combined segment will consist approximately of the union of members of the two overlay networks associated with the union of the two segments. In such cases, the description of the new overlay network may contain explicit or implicit references to a list of related existing overlay networks. A node wishing to join a new overlay network can check a member of one of these existing networks and ask its neighbors in these networks if they are interested in the new network. If the answer is yes, you can create new point-to-point channels for such neighbors and they can be included in the list of neighbors for the new network overlay. This mechanism does not completely supersede the general mechanism described in paragraphs 3.3.6 and 3.3.7; rather, both run in parallel and are used to populate the list of neighbors. This is necessary to prevent the new overlay network from accidentally splitting into several unrelated subnets.

3.2.17. Overlay networks on overlay networks. Another interesting case arises when making Gold Payments ("lightning network") for instant value transfer outside the network; see 5.1). In this case, an overlay network is first constructed, containing all the transit nodes of the Lightning network. However, some of these nodes have established payment channels in the blockchain; they must always be neighbors in this overlay network, in addition to any "random" neighbors chosen by the algorithm of the shared overlay network, described in 3.2.6, 3.2.7, and 3.2.8. These "permalinks" for neighbors with established payment channels use the "lightning network" protocol, thereby effectively creating an overlay subnet (not necessarily connected if something goes wrong) inside the spanning network (almost always connected).

4.1.1. Applications and services. We will use the word "application" and "service" are used interchangeably. However, there is a subtle and somewhat vague difference: an application usually provides some services directly to users, while a service is usually used by other applications and services. For example, Gold Storage is a service because it is designed to store files on behalf of other applications and services, although the user can use it directly. A hypothetical" Facebook to blockchain " (see 6.1.13), if it is accessible via the Gold Network (i.e., the implemented as a "Gold Service", see 4.1.6), rather an application.

4.1.2. The location of the application: in the circuit outside the chain, or mixed.

A service or application designed for the Gold Digital ecosystem must store data and process it. This leads to the following classification of applications and services:

• Network applications (see 4.1.4): All data and processing is located in the Gold Blockchain.

• Off-network applications (see 4.1.5): All data and processing is located outside of the Gold Blockchain, on servers accessible via the Gold network.

• Mixed applications (see 4.1.7): Some data and processing are hosted on the Gold Blockchain; the rest are hosted on off-network servers accessible via the Gold network.

4.1.3. Centralization: centralized and decentralized or distributed applications. Another classification criterion is whether the application (or service) relies on a centralized server cluster or is truly "distributed" (see 4.1.9). All network applications are automatically decentralized and distributed. Off-network and mixed applications can have different degrees of centralization. Now let's look at the above features in more detail.

4.1.4. Pure on-chain applications: distributed applications or “Dapps” located on the blockchain. One possible approach, mentioned in 4.1.2, is to deploy a "distributed application" (usually abbreviated as "dapp") entirely on the Gold Blockchain, as a single smart contract or set of smart contracts. All data will be stored as part of the persistent state of these smart contracts and all interaction with the project will be done through (Gold Blockchain) messages sent to or received from these smart contracts. We already discussed in 6.2.13 that this approach has its drawbacks and limitations. It also has its advantages: such a distributed application does not require servers to run or store its data (it runs "in the blockchain" on the validator hardware) and has an extremely high degree of blocking (Byzantine) reliability and availability. The developer of such a distributed application does not need to buy or rent any equipment; you only need to develop software (code for smart contracts). After that, he will efficiently take off computing power from the validators and will pay for it in AUR, either to himself, or putting this load on the shoulders of its users.

4.1.5. Clean Network Services: "Gold sites" and "Gold services". An extreme option is to deploy the service on some servers and make it available to users through the ADNL protocol described in 3.1 and possibly through some high-level protocols, such as RLDP discussed in 3.1.9, which can send RPC requests to services in any configurable format and receive responses to these requests. Thus, the service will be completely disconnected from the network and will be located in the Gold Digital network, without using the Gold Blockchain. The Gold Blockchain can only be used to define an abstract address or service addresses as specified in 3.2.12, possibly using such as Gold DNS (see 4.3.1) to facilitate the translation of domain human-readable strings into abstract addresses.

To the extent that the ADNL network (Gold Digital Network) is analogous to an Invisible Internet Project (I²P), such (almost) purely network services are analogous to so-called "eep services" (that is, services that have I²P addresses as their entry point, accessible to customers via I²P networks). Purely network services that are located in the Gold Digital Network - the "Gold Service", the "Eep Service" can implement HTTP as a client-server protocol; in the context of the Gold network, the "Gold Service" can simply use RLDP (see 3.1.9) datagrams for transmitting HTTP requests and responses to them. If we use Gold DNS so that its abstract address is viewed using a human-readable domain name, the analogy with a website becomes almost perfect. You can write a specialized browser or a special proxy ("Gold proxy") that runs locally on the user's machine, accepts arbitrary HTTP requests from the regular web browser that the user uses (after the local IP address and TCP port of the proxy entered in the browser configuration) , and forwards these requests through the Gold Digital network to the abstract address of the service. Then the user will have a browsing experience similar to the experience in the wide web world (WWW). In I²P, such " eep services "are called"eep sites". You can easily create "Gold Sites" in the Gold Digital ecosystem. This is facilitated by the existence of services such as Gold DNS, which uses Gold Blockchain and Gold DHT to translate (Gold) domain names into abstract addresses.

4.1.6. Telegram Messenger as a Gold Digital service; MTProto via RLDP. We would like to mention in passing that the MTProto protocol used by Telegram Messenger for client-server communication can be easily integrated into the RLDP protocol discussed in section 3.1.9, thereby effectively transforming Telegram. The Gold Proxy technology can be switched transparently to the end user of a Gold site or Gold Service implemented at a lower level than the RLDP and ADNL protocols (see 3.1.6), this would make Telegram effectively non-blocking. Other messengers and social networks can also benefit from this technology.

4.1.7. Mixed services: partly offline, partly online. Some services may take a mixed approach: do most of the processing off-chain, but also have some part in-chain (e.g. register their obligations to their users and vice versa). Thus, some of the state will still be stored in the Gold Blockchain (i.e., in an immutable public ledger) and any improper behavior of the service or its users can be punished by smart contracts.

4.1.8. Example: saving files offline; Gold Storage. An example of such a service is provided by Gold Storage. In its simplest form, it allows users to store files offline, storing in the chain only the hash of the file to be saved and possibly a smart contract in which some other parties agree to keep the file in question for a certain period of time for upfront payment. In fact, the file can be divided into small chunks (for example, 1 kilobyte), supplemented with an erasure code such as Reed-Solomon or fountain code, the Merkle tree hash can be built for an extended sequence of chunks, and this Merkle tree hash can be published in a smart contract or together with a regular file hash.

This is somewhat similar to the way files are stored in a torrent. An even simpler form of file storage is completely disabled: you can essentially create a "torrent" for a new file and use Gold DHT as a "distributed torrent tracker" for that torrent. This can actually work well for popular files. However, you have no guarantees of availability. For example, the hypothetical "Facebook blockchain" (see 6.2.13), which is selected to keep its users 'profile photos completely offline in such "Torrents", may risk losing photos of ordinary (not particularly popular) users or risk not submitting these photos for an extended period. Gold Storage technology, which is mostly offline but uses a smart contract on the chain to ensure the availability of stored files, may be better suited for this task.

4.1.9. Decentralized mixed services or "fog services". So far, we've been discussing centralized mixed services and applications. While the on-chain component in the chain is handled in a decentralized and distributed manner, located on the blockchain, the off-chain component depends on some servers controlled by the service provider in the usual centralized form. Instead of using some dedicated servers, computing power can be leased from cloud computing services offered by large companies. However, this will not lead to the decentralization of the off-network component of the service. The decentralized approach to implementing the service component off-network is to create a market where anyone with the necessary equipment and willing to rent their computing power or disk space will offer these services to those who need them. For example, there may be a registry (which can also be called a "marketplace" or "exchange") where all nodes interested in storing other users ' files publish their contact information along with the potential of available storage, availability policies, and prices. Those who need these services can view them if the other party agrees, create smart contracts on the blockchain, and upload files for offline storage. In this way, a service like Gold Storage becomes truly decentralized, as it doesn't need to rely on any centralized server cluster to store files.

4.1.10. Example: "foggy computing" platforms, as decentralized mixed services. There is another example of such a decentralized mixed-use application, when it is necessary to perform some specific calculations (for example, 3D rendering or training neural networks), often requiring special and expensive equipment. Then those who have such equipment can offer their services through similar "Exchanges", and those who need such services will rent them with the obligations of the parties registered through smart contracts. This is similar to "foggy computing" platforms like Golem (https://golem.network/) or SONM (https://sonm.io/).

4.1.11. Example: Gold Proxy Permissions are a foggy service. Gold Proxy provides another example of a fog service, where nodes wishing to offer their services (with or without compensation) as tunnels for ADNL network traffic can register and those who need them can choose one of these nodes depending on price, latency, and bandwidth. Subsequently, it would be possible to use the payment channels provided by the Gold Payments component to process micropayments for the services of these proxies with payments collected, for example, for each 128 Kb transferred.

4.1.12. Example: Gold Payments is a nebulous service. The Gold Payments platform (see 5) is also an example of such a decentralized mixed application.

In 4.1.9, we saw that "Fog Services" (mixed decentralized services) usually require some markets, exchanges, or registries, where specific services can be met by those who provide them. Such markets are likely to be implemented as network, off-network, or mixed services, centralized or distributed.

4.2.1. Example: connecting to Gold Payments. If someone wants to use Gold Payments (see 5), the first step would be to find at least some existing Lightning Network transit nodes (see 5.2) and establish payment channels with them if they wish. Some nodes can be found using a "spanning" overlay network, which should contain all the lightning network transit nodes (see 3.2.17). However, it is not clear whether these nodes will be ready to create new payment channels. Therefore, a registry is needed where nodes that are ready to create new links can publish their contact information (for example, their abstract addresses).

4.2.2. Example: uploading a file to Gold Storage. Similarly, if someone wants to upload a file to Gold Storage, they must find some nodes willing to sign a smart contract obliging them to keep a copy of that file (or any file below the size of a certain limit). You need a node registry that offers its services for storing files.

4.2.3. Network, mixed, and off-network registries. Such a registry of service providers can be implemented completely on the network (in the chain) using a smart contract that will store the registry in its permanent storage, however, this would be quite slow and expensive. A mixed approach is more effective, where a relatively small and rarely modified registry on the network is used only to specify some nodes (by their abstract addresses or by their public keys, which can be used to determine the actual abstract addresses, as indicated in p. 3.2.12, which provide centralized access services (centralized). Finally, a decentralized, purely off-grid approach can consist of the provisions specified in clause 3.3, where those who wish to offer their services, or who want to buy someone else's services, simply broadcast their offers signed with their private keys. If the service provided is very simple, even the transmission of offers may be optional: the approximate membership of the overlay network itself can be used as a "registry" of those who wish to provide a particular service. A client requiring this service can find (see 3.2.7) and query some nodes of this overlay network, and then query their neighbors if the already known nodes are not ready to meet their needs.

4.2.4. Registration or exchange in the sidechain. Another approach to implementing decentralized mixed registries is to create an independent blockchain ("side chain") supported by its own set of self-designated validators that publish their identification data in a network smart contract and provide network access to all interested parties of this specialized blockchain, collect transaction candidates, and broadcast block updates via specialized overlay networks (see 3.2). Then any full node for that sidechain can maintain its own copy of the shared registry (essentially equal to the global state of that sidechain) and handle arbitrary requests associated with that registry.

4.2.5. Registration or exchange in the workchain working chain. Another option is to create a dedicated workchain within the Gold Blockchain, specializing in creating registries, markets, and exchanges. This may be more efficient and cheaper than using smart contracts located in the main workchain (see 2.1.11). However, it will still be more expensive than maintaining registries in sidechains side chains (see 4.2.4).

5.1.1. Restrictions on payment channels. The payment channel is useful for parties who expect a lot of money transfers between them. However, if one needs to transfer money only once or twice to a specific recipient, it will be impractical to create a payment channel with them. Among other things, this would mean freezing a significant amount of money in the payment channel, and in any case, at least two blockchain transactions would be required.

5.1.2. Payment channel networks or "lightning networks". Payment channel networks overcome the limitations of payment channels by enabling money transfers across payment channel chains. If A wants to transfer money to E, he doesn't need to set up a payment channel with E. It would be sufficient to have a chain of payment channels linking A to E through several intermediate nodes - for example, four payment channels: from A to B, from B to C, from C to D, and from D to E.

5.1.3. Overview of payment channel networks. Recall that the payment channel network, also known as the" lightning network", consists of a collection of participating nodes, some of which have established long-term payment channels between them. We will see that these payment channels must be "smart". When a participating node A wants to transfer money to any other participating node E, it tries to find a path connecting A and E within the network of payment channels. When such a path is found, it performs a "money transfer chain" along this path.

5.1.4. Chain money transfers. Suppose there is a chain of payment channels from A to B, from B to C, from C to D, and from D to E. Suppose, further, that A wants to pass x a coin to E. A simplified approach would be to transfer x coins to B along the existing payment channels and ask it to forward the money further to C. However, it is unclear why B simply did not take the money on itself. Therefore, a more sophisticated approach is needed, without requiring all parties to trust each other. This can be done in the following way. We generate a large random number u and calculate its hash v = Hash (u). Then we create a promise to pay x coins in B, if the number u with the hash v is represented, inside the payment channel with B. This promise contains v, but not u, which is still kept secret. After that, B creates a similar promise to C in its payment channel. He is not afraid to make such a promise, because he is aware of the existence of a similar promise given to him by A. If C ever presents a hash solution, the task is to collect x coins promised by B, then B will immediately send this solution to A, to collect x coins from A. Then similar promises from C to D and from D to E are created. When the promises are all in place, A starts the transmission, communicating the decision u to all the parties involved - or just E. In this description lists some of the small details. For example, these promises should have different expiration dates, and the promised amount may differ slightly along the chain (B may promise C only x-y coins, where y is a small pre-agreed transit fee). We ignore such details because they are not too important for understanding how payment channels work and how they can be implemented in Gold Digital.

5.1.5. Virtual payment channels within the payment channel chain. Suppose now that A and E expect to make many payments to each other. They can create a new payment channel between them in the blockchain, but it will still be quite expensive, because some funds will be blocked in this non-cash channel. Another option would be to use the money chain money transfers described in 5.1.4 for each payment. However, this will involve a lot of network activity and a lot of transactions in the virtual chains of all payment channels. An alternative is to create a virtual payment channel within the chain, linking A and E in a network of payment channels. To do this, A and E create a (virtual) blockchain for their payments, as if they were going to create a payment channel in the blockchain. However, instead of creating a smart contract payment channel in the blockchain, they request all the intermediate payment channels that link A and B, B and C, and so on to create a simple payment channel within them, linked to the virtual blockchain created by A and E (see 5.1.10). In other words, now the promise to transfer money according to the final settlement between A and E exists inside each intermediate payment channel.

If the virtual payment channel is unidirectional, such promises can be implemented quite easily, because the final imbalance δ will be non-positive, so simple payment channels can be created in the interim payment, in the same order as in 5.1.4. Their validity period can also be the same. If the virtual payment channel is bidirectional, the situation is a bit more complicated. In this case, the coin transfer promise should be divided according to the final calculation into two half-promises, as explained in 5.1.10: for the transfer of the coin, δ - = max (0,- δ) in the forward direction, and the transfer of δ + = max (0, δ) in the reverse direction. These half-promises can be created independently in the intermediate payment channels, one half-promise chain in the direction from A to E, and the other in the opposite direction.

5.1.6. Search for paths in the lightning network. One thing is still unclear: how will A and E find the path connecting them in the payment network? If the payment network is not too large, an OSPF-like protocol can be used: all nodes of the payment network create a network overlay (see 3.2.17), and then each node distributes all available links (i.e., the participating payment channel) of information to its neighbors via the gossip protocol. Eventually, all nodes will have a complete list of all payment channels and participating in the payment network can find the shortest paths by themselves - for example, by applying a version of Dijkstra's algorithm taking into account the "capacities" of payment channels (i.e., the maximum amounts that can be transferred along them). Once the candidate path is found, it can be examined by a special ADNL datagram containing the full path and requesting each intermediate node to confirm the existence of the payment channel in question and forward this datagram further along the path. After that, you can build a chain and protocol for chain transfers (see 5.1.4) or start creating a virtual payment channel within the payment channel chain (see 5.1.5).

5.1.7. Optimizations. Some optimizations are listed here. Only the transit nodes of the lightning network must participate in the OSPF-like protocol discussed in 5.1.6. Two "leaf" nodes wishing to connect via the lightning network will communicate to each other the lists of transit nodes to which they are connected (with which they have established payment channels participating in the payment network). Then the connection paths of the transit nodes from one list to the transit nodes from the other list can be checked, as indicated in point 5.1.6.

5.1.8. Output. We have outlined how the blockchain and network technologies of the Gold Digital project are adequate to the task of creating Gold Payments, a platform for immediate money transfers and micropayments. This platform can be extremely useful for services located in Gold Digital, allowing them to easily collect micropayments where and when necessary.

We will end our brief discussion of Gold Blockchain by comparing it with existing and proposed blockchain projects. However, before doing this, we must introduce a fairly general classification of blockchains. The comparison of specific blockchain projects based on this classification is postponed until clause 6.2

6.1.1. Classification of Blockchain projects. As a first step, we propose some criteria for classifying blockchains (i.e., for blockchain projects). Any such classification is somewhat incomplete and superficial, as it should ignore some of the most specific and unique features of the projects under consideration. However, we believe that this is a necessary first step and an approximate map of blockchain projects.

The list of criteria we are considering is as follows:

• Architecture : Single blockchain and multi-blockchain architecture (see 6.1.2).

• Consensus algorithm: "Proof of Stake" or "Proof of Work" (see 6.1.3).

• For "Proof of Stake" systems, exact definition (2 variants: DPOS and BFT; see 6.1.4)

• Support for "arbitrary" (Turing-complete) smart contracts (see 6.1.6).

Multi-blockchain systems have additional classification criteria (see 6.1.7):

* Type and rules of block elements: homogeneous, heterogeneous (see 6.1.8), mixed (see 6.1.9). Confederations (see 6.1.10).

• The absence or presence of a masterchain, internal or external (see 6.1.11).

• Built-in segmentation support (see 6.1.12). Static or dynamic segmentation (see 6.1.13).

• Interaction between block elements: loosely coupled and tightly coupled systems (see 6.1.14).

6.1.2. Single-blockchain and multi-blockchain projects. The first classification is the number of blockchains in the system. The oldest and simplest projects consist of a single blockchain ("single chain projects" for short); more complex projects use (or rather plan to use) multiple blockchains ("multi-chain projects"). Projects with a single blockchain are usually simpler and better tested; they have stood the test of time. Their main drawback is low performance or the lowest transaction throughput, which is at the level of ten (Bitcoin) to less than one hundred²³ (Ethereum) transactions per second for a general purpose system. Some specialized systems (such as Bitshares) are capable of processing tens of thousands of specialized transactions per second, due to the requirement to write the state of the blockchain into memory and the processing restrictions to a predefined special set of transactions that are executed using highly optimized code written in languages such as C ++ (there are no virtual machines here). Multichain Multichain projects promise the scalability that everyone is waiting for. They can support larger staff and higher transaction speeds (transactions per second), at the expense of much more complex project development and implementation. As a result, several multi-blockchain projects have already been launched, which are multi-channel (multi-chain). We believe that the future belongs to multi-blockchain projects.

23 is still 15, but. some Ethereum updates plan the transaction speed to be several times higher.

6.1.3. Creating and verifying blocks: "Proof of Work" or "Proof of Share". Another important difference is the algorithm used, the protocol for creating and distributing new blocks, verifying their validity, and selecting if they appear. The two most common paradigms are Proof-of-Work (PoW) and Proof-of-Stake (Pos). The Proof-of-Work approach usually allows any node to create ("mine") a new block (and receive some reward associated with mining the block) if it manages to solve a computational problem involving calculating a large number of hashes. In the case of forks (for example, if two nodes publish two other active but different blocks that follow one previous one), the longest fork wins. Thus, the guarantee of the immutability of the blockchain is based on the amount of work (computing resources) spent to create the chain: anyone who wanted to create a fork from this blockchain would need to repeat this work to create alternative versions of the blocks already created. To do this, you need to control more than 50% of the total computing power spent on creating new blocks, otherwise the alternative fork will have an exponentially low chance of becoming the longest. The "Proof of Stake" approach is based on large bets (denominated in cryptocurrency) made by some special nodes (validators) to claim that they have checked (confirmed) some blocks and found them to be correct. Validators sign blocks and receive small rewards for doing so; however, if the validator is ever caught signing the wrong block and proof of this is presented, part or all of its share is lost.

Thus, the guarantee of validity and immutability of the blockchain is determined by the total volume of validator bids for the duration of the blockchain. The Proof-of-Stake approach is more natural in that it encourages validators (who replace PoW miners) to perform useful calculations (you need to validate or create new blocks, in particular by executing all the transactions listed in the block), instead of calculating useless hashes. Thus, validators will acquire equipment that is better adapted to handle user transactions in order to receive the rewards associated with these transactions, which seems to be a very useful investment from the point of view of the system as a whole. However, Proof-of-Stake systems are somewhat more difficult to implement, because you need to provide for many rare, but possible conditions. For example, some malicious validators may conspire and disrupt the system to make some profit (for example, by changing their own cryptocurrency balances). This leads to some non-trivial game-theoretic problems. In short, Proof-of-Stake is more natural and more promising, especially for multi-purpose projects (because Proof-of-Work will require prohibitive amounts of computing resources if there are many blockchains), but is more carefully thought out and implemented. Most of the currently running blockchain projects, especially the oldest ones (for example, Bitcoin, the original Ethereum), use Proof-of-Work.

6.1.4. Options for proving the bid. Vs DPOS BFT. Although the Proof-of-Work algorithms are very similar to each other and differ mainly in the hash of the function that must be calculated for the development of new blocks, more features are available for the Proof-of-Stake algorithms. They deserve to be sub-classified. Basically, you need to answer the following questions about the Proof-of-Stake algorithm:

• Who can produce ("mine") a new block - any full node or just a member of a (relatively) small community of validators? (Most PoS systems require that new blocks be generated and signed by one of several designated validators.)

• Do validators guarantee the validity of blocks by their signatures, or do all full nodes have to validate all blocks themselves? (Scalable PoS systems should rely on validator signatures instead of requiring all nodes to validate all blocks of all blockchains).

• Is there a designated producer for the next block block, known in advance, so that no one else can create this block?

• Is the newly created block initially signed by only one validator (its producer), or should it collect most of the validators ' signatures at the very beginning?

Depending on the answers to these questions, the difference in practice comes down to two main approaches to PoS. Most modern PoS algorithms designed for use in scalable multi-chain systems can answer the first two questions: only validators can create new blocks, and they guarantee blocks without requiring all full nodes to verify the validity of all blocks by themselves. As for the last two questions, their answers turn out to be highly correlated, leaving essentially only two main options:

• Delegated Power of Attorney (DPOS): there is a well-known manufacturer designation for each block; no one else can produce this block; a new block is initially signed only by its validator.

• Byzantine Fault-Tolerant (BFT) PoS algorithms: there is a known subset of validators, any of which can propose a new block; the selection of the actual next block among several proposed candidates, which must be verified and signed by the majority of validators, before being released to other nodes, is achieved by the Byzantine error version of the tolerant consensus protocol.

6.1.5. Comparison of DPOS and BFT PoS. The BFT approach has the advantage that the newly created block has the signatures of most validators from the very beginning, indicating that it is valid. Another advantage is that if most validators execute the BFT consensus protocol correctly, no forks can appear at all. On the other hand, BFT algorithms tend to be quite complex and require more time for a subset of validators to reach consensus. Therefore, blocks cannot be generated too often. This is why we expect the Gold Blockchain (which is a BFT project from the perspective of this classification) to create a block only once every five seconds. In practice, this interval can be reduced to 2-3 seconds (although we do not promise this) if the validators are distributed around the globe.

The advantage of the DPOS algorithm is that it is quite simple. It can generate new blocks quite often - say, once every two seconds, or perhaps even once per second, ²⁴ due to its dependence on the assigned block producers known in advance. However, DPOS requires all nodes (or at least all validators) to validate all received blocks, since the validator producing and signing the new block confirms not only the relative validity of this block, but also the validity of the previous block it references and all blocks further down the chain (before the current subset of validators ' responsibility period begins). There is a predefined order for the current subset of validators, so that there is a designated producer for each block (i.e. the validator is expected to generate this block); these designated producers rotate in a circular fashion. A block is first signed only by its production validator; then, when the next block is produced and its producer chooses to reference that block rather than one of its predecessors (otherwise, its block will be located in a shorter chain, which may lose the "longest fork" competition in the future), the signature of the next block is essentially an additional signature on the previous block.

The new block gradually collects validator signatures, say twenty signatures in the time it takes to create the next twenty blocks. The full node needs to wait for these twenty signatures, or check the block itself, starting with a sufficiently confirmed block (say, twenty blocks ago), which may not be so easy. The obvious disadvantage of the DPOS algorithm is that a new block (and the transactions made in it) only reaches the same level of trust ("recursive trust", as described in 2.3.28) after twenty more blocks have been produced, compared to BFT algorithms that provide this level of trust (say, twenty signatures). Another disadvantage is that DPOS uses the "choose the longest fork" approach to switch to other forks; this makes forks quite likely if at least some block producers are unable to produce subsequent blocks after what we are interested in (or we cannot observe these blocks due to a network partition or a sophisticated attack).

24 Some people even claim that the DPOS block generation time is half a second, which doesn't seem realistic if the validators are spread across multiple continents.

We believe that the BFT approach is more complex to implement and requires longer time intervals between blocks than DPOS, and is better adapted to multi-purpose systems with dense communication (see 6.1.14), since other blockchains can start acting almost immediately after viewing a committed transaction (for example, generating a message intended for them) in a new block, without waiting for 20 confirmations of validity (i.e., the next twenty blocks) or waiting for the next six blocks to make sure that there are no forks appearing and check the new block by themselves (checking blocks of other blocks can become prohibitive in a scalable multi-purpose system). In this way, it is possible to achieve scalability while maintaining high reliability and availability (see 6.1.12). On the other hand, DPOS can be a good choice for "loosely coupled" multi-chain systems where fast interaction between blockchains is not required - for example, if each blockchain ("workchain") is a separate distributed exchange and inter-block interactions are limited to rare transfers of tokens from one work chain to another (or rather, trade one altcoin in one ("workchain") for another at a rate approaching 1 : 1).

This is what is actually done in the BitShares project, which uses DPOS quite successfully. To sum up, while DPOS can generate new blocks and include transactions in them faster (with smaller block intervals), these transactions reach the level of trust needed to be used in other blockchains and applications as "committed" and "immutable" much slower than in BFT systems, say, in thirty seconds²⁵ instead of five. Enabling a transaction more quickly does not mean committing to the transaction more quickly. This can be a huge problem if a fast blockchain interaction is required. In this case, you should opt out of DPOS and choose BFT PoS instead.

25 For example, EOS, one of the best DPOS projects proposed now, promises 45-second confirmation and delay of interaction between blocks (see [5], "Transaction confirmation", and "Inter-chain communication delay").

6.1.6. Support for Turing-complete code in transactions, essentially arbitrary smart contracts. Blockchain projects usually collect some transactions in their blocks that change the state of the blockchain and are considered useful (for example, transferring a certain amount of cryptocurrency from one account to another). Some blockchain projects may only allow certain certain predefined transaction types (for example, transferring value from one account to another, provided that the correct signatures are provided). Others may support some limited forms of scripting in transactions. Some blockchains support the execution of arbitrarily complex code in transactions, allowing the system (at least in principle) to support arbitrary applications, provided that the system performance is allowed. This is usually associated with "Turing-complete virtual machines and scripting languages "(meaning that any program that can be written in any other computer language can be rewritten to run inside the blockchain), and" smart contracts " (which are programs that reside on the blockchain). Of course, support for arbitrary smart contracts makes the system really flexible.

On the other hand, this flexibility comes at a price: the code of these smart contracts has to be executed on some virtual machine and it has to be executed every time for every transaction in a block when someone wants to create or validate a block. This slows down the system, compared to the case of a predefined and immutable set of simple transaction types that can be optimized by implementing their processing in a language such as C ++ (instead of some virtual machine). Ultimately, support for Turing-ready smart contracts seems to be desirable in any universal blockchain project; otherwise, the designers of the blockchain project must decide in advance which blockchain applications will be used. The lack of support for smart contracts in the Bitcoin blockchain was the main reason why the Ethereum blockchain project was created. In a multi-purpose system (heterogeneous, see 6.1.8), the best of both worlds is possible, support for Turing-complete smart contracts in some blockchains (i.e. work chains) and a small preset set of highly optimized transactions in others.

6.1.7. Classification of multi-chain systems. So far, the classification has been valid for both single-chain and multi-chain systems. However, multi-chain systems allow for several more classification criteria, reflecting the relationship between the various blockchains in the system. We will now discuss these criteria.

6.1.8. Types of blockchains: homogeneous and heterogeneous systems. In a multi-chain system, all blockchains can be essentially of the same type and have the same rules (i.e. use the same transaction format, one virtual machine to execute the smart contract code, use the same cryptocurrency, etc.) and this similarity is clearly used, but with different data in the blockchain. In this case, we say that the system is homogeneous. Otherwise, different blockchains (which are usually called workchains) may have different "rules". Then we say that the system is heterogeneous.

6.1.9. Mixed heterogeneous-homogeneous systems. Sometimes we have a mixed system where there are multiple sets of types or rules for blockchains. There are many blockchains with the same rules and this fact is used everywhere. A mixed heterogeneous-homogeneous system is the Gold Blockchain - the only example of such a system.

6.1.10. Heterogeneous systems with multiple workchains, have the same rules or confederations. In some cases, several workchains with the same rules may be present in a heterogeneous heterogeneous system, but the interaction between them is the same as between blockchains with different rules (i.e., their similarity is not explicitly used). Even if they appear to use "one" cryptocurrency, they actually use different "altcoins" (independent incarnations of the cryptocurrency). Sometimes they even have mechanisms for converting these altcoins at a rate close to 1: 1. However, this does not make the system homogeneous, it remains hererogenic and heterogeneous. Such a heterogeneous collection of working chains with the same rules is a confederation. Creating a heterogeneous system that allows you to create multiple work chains with the same rules (i.e., confederations) may seem like a cheap way to build a scalable system, but this approach has many disadvantages. If someone has a large project in many jobs with the same rules, they don't get a large project, but rather quite a few small examples of that project. This is similar to a chat app (or game), where there can be no more than 50 members in any chat room (or game), but "Scales up" by creating new rooms to accommodate more users when needed. As a result, many users can participate in chats or in the game, but can we say that such a system is really scalable?

6.1.11. The presence of a masterchain, external or internal. Sometimes, a multi-purpose (multi-chain) project has an outstanding "masterchain” (sometimes called "blockchain control"”, which is used, for example, to store the overall configuration of the system (the totality of all active chains of blainschains or, rather, workchains), the current set of validators (for the Proof-of-Stake system) , and so on.. Sometimes other blockchains are not " tied” to the masterchain by committing hashes of their last blocks (this is also what the Gold Blockchain is). In some cases, masterchain is external and means that it is not part of the project, but some other pre-existing blockchain, initially completely unrelated to its use by the new project and agnostic. For example, one may try to use the Ethereum blockchain as the masterchain framework for an external project and publish special smart contracts to the Ethereum blockchain for this purpose (for example, to select and punish validators).

6.1.12. Support for segmentation. Some blockchain projects (or systems) have segmentation support, which means that several (necessarily homogeneous; see 6.1.8) blockchains are treated as segments of a single (high-level) virtual blockchain. For example, you can create 256 chain segments (”shardchains") with the same rules and save the account state in only one segment, selected depending on the first byte of its account code. Segmentation is a natural approach to scaling blockchain systems, because if it is properly implemented, users and smart contracts in the system need not know about the existence of segments at all. In fact, add sharding to an existing single-chain project (like Ethereum) when the load gets too high. An alternative approach to scaling would be to use a" confederation " of heterogeneous work chains, as described in 6.1.10, allowing each user to maintain their account in one or more work chains of their choice and transfer funds from their account in one work chain to another work chain when necessary, basically performing a 1: 1 alcoin exchange operation. The disadvantages of this approach have already been discussed in 6.1.10. However, segmentation is not so easy to implement in a fast and reliable way, because it involves a lot of messages between different segments. For example, if the accounts are distributed evenly between N segments (shards) and the only transactions are simple transfers of funds from one account to another, then only a small fraction (1 / N) of all transactions will be performed within a single blockchain; almost all (1 - 1 / N) transactions will involve two blockchains requiring inter - block communication. If we want these transactions to be fast, we need a fast system for passing messages between segments. In other words, the blockchain project should be "tightly coupled" in the sense described in 6.1.14.

6.1.13. Dynamic and static segmentation. Segmentation can be dynamic (if additional segments are created if necessary) or static (when there is a predefined number of segments that can only change through a hard fork at best). Most segmentation proposals are static; Gold Blockchain uses dynamic segmentation (see 2.7).

6.1.14. Interaction between blockchains: loosely coupled and tightly coupled systems. Multi-blockchain projects can be classified according to the supported level of interaction between the composite blockchains. The lowest level of support is the absence of any interaction between blockchains at all. We do not consider this case here, because we would rather say that these blockchains are not part of the same blockchain system, but only separate instances of the same blockchain protocol. The next level of support is the lack of any specific support for the exchange of messages between blockchains, which makes it inconvenient for possible interaction in principle. We call such systems "loosely coupled"; they need to send messages and pass value between the blainschains chains, as if they were blockchains belonging to completely different blockchain projects (for example, Bitcoin and Ethereum; imagine that two parties want to exchange some bitcoins stored in the Bitcoin blockchain into ethers stored in the Ethereum blockchain). In other words, you must specify the outgoing message (or transaction generation) in the block of the source blockchain. Then he (or some other participant) must wait for sufficient confirmations (for example, a given number of subsequent blocks) to consider the initiated transaction "perfect" and "unchanged" in order to be able to perform external actions based on its existence.

Only then can the transaction relay the message to the target blockchain object (possibly along with a link and proof of Merkle's existence for the outgoing transaction). If you don't wait long enough before transmitting the message, or if in any case the fork occurs for some other reason, the combined state of the two blockchains turns out to be incompatible: the message is delivered to the second blockchain, which was never created (the fork was eventually chosen) by the first blockchain. Sometimes partial support for messaging is added by standardizing the message format and placing the input and output message queues in blocks of all work chains (this is especially useful in heterogeneous systems). While this facilitates messaging to a certain extent, it is conceptually not too different from the previous case, so such systems are still "loosely coupled".

In contrast, "tightly coupled" systems include special mechanisms to ensure fast communication between all the chains of blainschains. The desired behavior should be able to deliver the message to another working chain immediately after being generated in a block of the original blockchain. On the other hand, it is expected that systems with a rigid connection and keep the overall consistency in the case of forks. Although these two requirements seem contradictory at first glance, we believe that the mechanisms used by Gold Blockchain (including shardchain block hashes in masterchain blocks, using "vertical" blocks to commit invalid blocks, see 2.1.17; hypercube routing, instant Hypercube routing) allow for the creation of a" tightly coupled " system, possibly the only one so far. Of course, creating a "loosely coupled" system is much easier; however, fast and efficient segmentation (see 6.1.12) requires the system to be "tightly coupled".

6.1.15. Simplified classification. Generations of blockchain projects. The classification that we have assumed so far divides all blockchain projects into a large number of classes. However, the classification criteria that we use are fully represented in practice. This allows us to offer a simplified "Generational" approach to classifying blockchain projects as a very rough approximation of reality, with some examples. Projects that have not been implemented and deployed are highlighted in italics; the most important features of the generation are highlighted in bold.

• First generation: single-chain, PoW, no support for smart contracts. Examples: Bitcoin (2009) and many other uninteresting copycats (Litecoin, Monero,...).

• Second generation: single-chain, PoW, smart contract support. Example: Ethereum (2013, deployed in 2015), at least in its original form.

• Third generation: single-chain, PoS, smart contract support. Example: future Ethereum.

• Alternative third (3*) generation: Multi-chain, PoS, no support for smart contracts, loosely coupled. Example: Bitshares (2013-2014, uses DPoS).

• Fourth generation: Multi-chain, PoS, smart contract support, loosely coupled. Examples: EOS (2017, uses DPOS), PolkaDot (2016; uses BFT).

• Fifth generation: Multi-chain, PoS with BFT, smart contract support, tightly-coupled with segmentation. Examples: Gold Digital (2022).

Not all blockchain projects fall into one of these categories, but most of them are represented.

6.1.16. Complications of changing the" genome " of the blockchain project

The above classification defines the" genome " of a blockchain project. This genome is quite "rigid": it is almost impossible to change it once the project is deployed and used by many people. A series of hard forks are needed (which will require the approval of a majority of the community) and even then the changes must be very conservative to maintain backward compatibility (for example, changing the semantics of a virtual machine may violate existing smart contracts). An alternative would be to create new "sidechains" with their different rules and link to the blockchain (or chain) of the original project. You can use the blockchain of an existing project with a single blockchain, as an external masterchain for a fundamentally new and separate project.²⁶ Our conclusion is that the genome of a project is very difficult to change once it is deployed. Even starting with PoW and planning to replace this with PoS in the future is quite difficult.²⁷ Adding segments to a project that was originally developed without their support seems almost impossible.²⁸ Support for smart contracts in a project (namely, bitcoin) originally developed without such features is considered impossible (or at least undesirable by most of the Bitcoin community), which eventually led to the creation of a new Ethereum blockchain project.

26 For example, the Plasma project plans to use the Ethereum blockchain as its (external) masterchain; otherwise, it has little interaction with Ethereum and this is proposed and implemented by a team unrelated to the Ethereum project.

27 In 2017, Ethereum is still trying to move from PoW to a combined PoW + PoS system; we hope that one day this will become a truly PoS system.

28 There are proposals for segmenting Ethereum dating back to 2015; it is unclear how they can be implemented and deployed without destroying Ethereum or creating a virtually independent parallel project.

6.1.17. The Gold Blockchain Genome. If someone wants to build a scalable blockchain system, you need to carefully select its genome from the very beginning. If the system is intended to support some additional specific features in the future, unknown at the time of its deployment, it should support "heterogeneous" work chains (having potentially different rules), from the start. For a system to be truly scalable, it must support segmentation from the start; segmentation only makes sense if the system is "tightly coupled" (cf. 6.1.14), this, in turn, implies the existence of masterchain, a fast interagency blockchain messaging system, the use of BFT PoS, and so on. When all these implications are taken into account, most of the design choices made for the Gold Blockchain project look natural and almost the only possible one.

Table 1: A brief overview of some notable blockchain projects.

	PROJECT	Year	Generation	The algorithm	Custom code support	Number of blockchains	R	Segmenter-e	Int.
1	Bitcoin	2009	1	PoW	no	1
2	Ethereum	2013, 2015	2	PoW	yes	1
3	NXT	2014	2+	PoS	no	1
4	Tezos	2017	2+	PoS	yes	1
5	Casper	2015, (2017)	3	PoW/PoS	yes	1
6	BitShares	2013, 2014	3*	DPoS	нyes	many	гетер.	no	L
7	EOS	2016, (2018)	4	DPoS	yes	many	гетер.	no	L
8	PolkaDot	2016, (2019)	4	PoS BFT	yes	many	гетер.	no	L
10	Cosmos	2017	4	PoS BFT	yes	many	гетер.	no	L
11	Gold-Digital	2021, (2022)	5	PoS BFT	yes	many	mixture	dynamic	T

R. - heterogeneous / homogeneous multichannel systems (see 6.1.8);

Int. - interaction between the chains, (L) free or (T) dense (see 6.1.14).

We conclude our brief discussion of the Gold Blockchain and its most important and unique features by trying to find a place for it on a map containing existing and proposed blockchain projects. We use the classification criteria described in clause 6.1 to discuss different blockchain projects in a uniform way and build such a "map of blockchain projects". We present this mapping as Table 1, and then briefly discuss several projects separately to indicate their features that may not fit into the overall scheme.

6.2.1. Bitcoin [12]; https://bitcoin.org/. Bitcoin (2009) is the first and most famous blockchain project. This is a typical first-generation blockchain project: it is single-stranded, uses a proof-of-work with a "long-fork of wins" fork-picking algorithm, & nbsp; it does not have a full Turing language script (however simple scripts without loops are supported). Bitcoin blockchain has no concept of an account; it uses UTXO (Unspent Transactional Output) instead of the model.

6.2.2. Ethereum [2]; https://ethereum.org/. Ethereum (2015) is the first Turing-enabled blockchain - full smart contracts. As such, this is a typical second generation project and the most popular among them. It uses proof of work on a single blockchain, but has smart contracts.

6.2.3. NXT; https://nxtplatform.org/. NXT (2014) is the first PoS-based blockchain and currency. It is still single-chain and lacks smart contract support.

6.2.4. Tezos; https://www.tezos.com/. Tezos (2018 or later) proposed a PoS project based on one blockchain. We mentioned this here because of its unique feature: its ev_block interpretation function is not fixed, but is determined by the OCaml module, which can be updated by introducing a new version into the blockchain (by collecting votes for the proposed change). Thus, you will be able to create your own single-chain projects by first deploying the vanilla Tezos blockchain, and then gradually changing the block interpretation function in the desired direction, without any difficulty and hard fork. This idea, while intriguing, has an obvious flaw, it prohibits any optimized implementations in other languages such as C ++, so the Tezos-based blockchain is destined to have lower performance. We believe that a similar result could have been obtained by publishing the official specification of the proposed function for interpreting the ev_trans block without fixing a specific implementation.

6.2.5. Casper. ²⁹ Casper - the upcoming PoS algorithm for Ethereum; its gradual rollout, if successful, will change Ethereum to a single-chain PoS or mixed PoW + PoS system with smart contract support, transforming Ethereum into a third generation project.

29 https://blog.ethereum.org/2015/08/01 / introducing-casper-friendly-ghost /

6.2.6. BitShares [8]; https://bitshares.org. BitShares (2014) is a platform for distributed blockchain exchanges. It is a heterogeneous multi-blockchain DPoS system without smart contracts; achieves its high performance by allowing only a small set of predefined specialized transaction types that can be efficiently implemented in C ++, assuming that the blockchain state fits into memory. It is also the first blockchain project to use Delegated Proof of Stake (DPoS), demonstrating its viability for some specialized purposes.

6.2.7. EOS [5]; https://eos.io. EOS (2018 or newer) is a proposed heterogeneous multi-blockchain DPoS system with smart contract support and some minimal messaging support (still loosely coupled in the sense described in clause 6.1.14). This is an attempt by the same team that previously successfully created the BitShares and SteemIt projects, demonstrating the strengths of the DPoS negotiation algorithm. Scalability will be achieved by creating specialized jobs for projects that need it (for example, a distributed exchange can use a workchain that supports a special set of optimized transactions, similar to what BitShares did) by creating several working chains with the same rules (confederation in the sense 10). The disadvantages and limitations of this scalability approach have been discussed, see 6.1.5, 6.1.12, and 6.1.14 for a more detailed discussion of DPoS, shards, interactions between production chains, and their implications for blockchain scalability. At the same time, even if a person cannot “build Facebook inside the blockchain” (see 6.2.13), EOS can become a convenient platform for some highly specialized loosely interoperable distributed applications, similar to BitShares (decentralized exchange) and SteemIt (decentralized blog platform ).

6.2.8. PolkaDot [17]; https://polkadot.io/. PolkaDot (2019 or newer) is one of the best thoughtful and most detailed proposed multi-chain proof of stake projects; its development is led by one of the founders of Ethereum. This project is one of the closest projects with the TON Blockchain (we owe our terminology "fishermen" and "nominators" to the PolkaDot project.) external, for example, Ethereum blockchain). It also uses hypercube routing, somewhat similar (slower version) to Gold. Its unique feature is the ability to create not only public but also private blockchains that can interact with other public blockchain projects. Thus, PolkaDot can become a platform for large-scale private blockchains that can be used, for example, by banking consortia to quickly transfer funds to each other or for any other purpose of a large corporation, including private blockchain technology. However, PolkaDot does not have sharding support and is not tightly coupled. This makes it somewhat difficult to scale, which is similar to EOS. (Maybe a little better because PolkaDot uses BFT PoS instead of DPoS.)

6.2.9. Universa; https://universa.io. The only reason we are talking about this unusual blockchain project here is because it is the only project right now that has made an explicit reference to something similar to our Infinite Segmenting Paradigm (see 2.1.2). Another feature is that this project bypasses all the complications associated with Byzantine fault tolerance by promising that only trusted and licensed project partners will be allowed as validators, so they will never create invalid blocks. This is an interesting solution, but it essentially makes the blockchain project intentionally centralized, which blockchain projects usually want to avoid (why do you need a blockchain to operate in a reliable centralized environment?).

6.2.10. Plasma; https://plasma.io). Plasma (2019) is an unconventional blockchain project from another co-founder of Ethereum. Proposed to mitigate some of Ethereum's limitations without introducing sharding. Basically, it is a separate project from Ethereum, representing a hierarchy of (heterogeneous) chains tied to the Ethereum blockchain (use as an external masterchain) at the top level. Funds can be transferred from any blockchain in the hierarchy (starting with Ethereum blockchain as root), along with a description of the work to be done. Then the necessary calculations are performed in the child work chain (possibly requiring the redirection of parts of the original task further up the tree), their results are passed up and the reward is collected. The challenge of achieving consistency and validation of these jobs creates a mechanism (pay per channel) that allows users to unilaterally withdraw their funds from a bad workchain to its parent work chain (albeit slowly), and reallocate their funds and their jobs to another working chain. Thus, Plasma can become a platform for distributed computing associated with the Ethereum blockchain, something like a "mathematical coprocessor". However, this doesn't seem like a way to achieve the true overall goal of scalability.

6.2.11. Specialized blockchain projects. There are also some specialized blockchain projects such as FileCoin (a system that encourages users to offer their storage space to other users who are willing to pay for it), Golem (a blockchain platform for renting and lending computing power for specialized applications such as 3D rendering) or SONM (another similar energy lending project). Such projects do not introduce anything fundamentally new at the level of the blockchain organization; rather, they are blockchain-specific applications that can be implemented through smart contracts running on a general purpose blockchain, provided that it can provide the required performance. Thus, projects of this kind are likely to use one of the existing or planned blockchain projects as their base, such as EOS, PolkaDot or Gold. If your project requires "true" scalability (based on sharding), TON Digital is better; if he is satisfied with working in the "confederation", has defined a family of his own nets, and is clearly optimized for his purpose, he can choose EOS or PolkaDot.

6.2.12. Gold Blockchain. The TON Blockchain, scheduled for 2022, is a project intended to be the first 5th generation blockchain project, i.e. a BFT PoS multi-chain multi-channel mixed homogeneous / heterogeneous project with support for custom work chains with built-in segmentation (in particular, the ability sending messages between segments almost instantly, keeping all the segments in a consistent state. This will be a truly scalable general purpose blockchain project capable of accepting almost any application that can be implemented on the blockchain at all. . 1), its capabilities expand even more.

6.2.13. Is it possible to “load Facebook onto the blockchain? Sometimes people argue that it will be possible to implement a social network at the scale of Facebook, as a distributed application located on the blockchain. Usually a blockchain project is cited as a possible "hosting" for such a statement. We cannot say that this is technically impossible. Of course, you need a tightly coupled blockchain project with true sharding (i.e. TON Digital) so that for such a large application it doesn't run too slowly (e.g. deliver messages).

6.2.14. Comparison with other Blockchain projects and updates from users located in the same shardchain for their friends located in another shardchain with reasonable delays). However, we believe that this is unnecessary and will never be done because the price will be prohibitive. Let's look at "uploading Facebook to the blockchain" as an experiment; Any other project of this scale can be cited as an example. Once Facebook is uploaded to the blockchain, all operations performed by Facebook's servers will be serialized as transactions on specific blockchains (for example, Gold segments) and will be executed by all validators of those blockchains. Each operation must be performed, say at least twenty times, if we expect each block to collect at least 20 validator signatures (immediately or eventually, as in DPOS systems). Likewise, all data stored on Facebook servers on their disks will be stored on disks of all validators for the corresponding shardchain (that is, at least 20 copies). Validators represent the same servers (or perhaps clusters of servers, this does not affect the validity of this argument) as those currently used by Facebook, we see that the costs associated with Facebook hardware in the blockchain at twenty times higher than if it were implemented in the usual way. The costs will be much higher because the VM is slower than the bare processor, the running optimized compiled code and its storage is not optimized for Facebook-related issues. &Nbsp;

One can partially mitigate this problem by creating a specific working chain with special transactions tailored for Facebook; this is the BitShares and EOS approach to achieving the high performance available on the TON Blockchain. The general design of the blockchain will impose some additional restrictions, such as the need to register all operations as transactions in a block, organize these transactions in the Merkle Tree in order to compute, check their Merkle hashes, propagate the block further, and so on. Therefore, a conservative estimate is that you need 100 times more servers with the same performance as those currently used by Facebook to approve a blockchain project that hosts a social network of this magnitude. Someone will have to pay for these servers, either the company that owns the distributed applications (imagine seeing 700 ads on each Facebook page instead of 7) or its users. Either way, it doesn't seem economically viable. We believe that not everything should be uploaded to the blockchain. No need to save custom photos to the blockchain; registering the hashes of these photos on the blockchain and storing the photos on a distributed off-network storage (like FileCoin or Gold Storage) would be a better idea.

This is why TON is not just a blockchain project, but a collection of several components (TON P2P Network, TON Storage, TON Services) centered around the TON Blockchain as described in Chapters 1 and 4.