Thoughts on the Mandala Network

• Ty Everett ([e-mail])

In the Mandala Network, there are three primary layers: the Transaction Processors at the core, the Overlay Services in the middle, and the Transacting Parties at the edges. Each of these layers can be further subdivided, as will be explored later. Transaction Processors create blocks, witness transactions and distribute merkle proofs. Overlay Services enable specialized tracking and management of tokens, and can encapsulate one another. Transacting Parties each use specialized applications to create transactions through wallets.

The core of the network comprises Transaction Processors, who have various tasks. These tasks are further divided into proof-of-work, block assembly, transaction aggregation and ordering, graph summarization, and edge validation, moving outwards. Transactions flow inwards through edge validators, who first check the validity of scripts. Subsequently, graph summarizers strip transactions down to their core graph elements, each being the input references they consume, their TXID, and the number of new outputs they create. Chains of related spends are also summarized at this layer.

Next, graphs are combined and ordered, ensuring that no double-spends occur and that no output is consumed before being created. As these graphs are aggregated together, larger and larger groups of transactions are combined, with each group containing a merkle root. Wherever these intermediate roots are computed, they're allowed to stream outwards. As we'll get to later, intermediate roots may also contain intermediate proof-of-work. Finally, the roots are all combined by the global block assembly layer and a candidate block header is made available to the proof-of-work network at the core.

The proof-of-work layer comprises hashing machines that work to solve blocks. New headers are announced and validated here, alongside other game-theoretic information that may be telegraphed between transaction processors about intermediate roots and double spends. At various network operations centers, the state of the system is coordinated and maintained, together with the enforcement of any legal actions. As new blocks are found, completed headers become known and are propagated outwards to all other layers of the network.

For every intermediate root that was computed, the completed header serves to extend the merkle proofs it encompasses with the merkle path nodes that link it upwards and backwards into the rest of the blockchain. As the higher-order nodes propagate downwards, at each point where an intermediate root was computed and finally down to all edge validators, the proofs are extended to completion. Even if there is a change near the top of the block with the high-order nodes (an intra-block reorganization) or across multiple blocks in the chain (an intra-block reorganization), these changes propagate downwards as they happen, and are accepted at every necessary layer with concerned roots or transactions.

From the perspective of the edge validation layer, scripts are first verified after requesting any necessary input transactions and/or proofs from the Transacting Parties via a graph-aware sync process. During this process, the edge validator may request any necessary information they don't already have from the transaction sender, enabling validation according to the rules of SPV.

The Transaction Processing Network's edge validator is entrusted with script evaluation, and submits stripped transaction artifacts inwards for summarization. As the transaction is included in larger and larger groups, the edge validation layer receives updates from the summarization layer about taller and taller (higher and higher order) merkle path nodes. These updates stream outwards to the rest of the network. As the transaction (and eventually its aggregated group graph) are moved around in the block, the aggregation layers update the summarization layer, and so on through to the outer layers.

The outer layers of the network can thus learn updates about the transaction's position in the block, even as the block is being assembled, and eventually receive not only a final proof, but also updates about reorganization and double spend notifications. At every layer of the core Transaction Processing Network, there is specialization and optimization. The more of the intermediary group assembly information publicly announced by transaction processors, the easier it will be for them to coordinate and validate each other's blocks — before, during, and after headers are solved.

In addition to the proof-of-work applied to a final block header, special transactions can be placed by Transaction Processors throughout the graphs they assemble and announce. These transactions (and the nonces they contain) can be placed strategically such that, when evaluated, the intermediate roots for high-order proof nodes contain leading zeroes. This optionally may serve to define an additional form of intermediary proof-of-work, without altering the protocol or the global proof-of-work system. This information is easily verifiable, and can flow outwards to improve confidence in the veracity of a given graph, even before the final block is found. High-order roots with leading zeroes can also be coordinated among competing transaction processors as a signaling mechanism.

Based on their respective degrees of trust, rates of block creation, and optionally — preemptive proof-of-work on intermediate high-order roots, transaction processors are free to expend as much or as little of their own computational power as desired on validating this information up front. Generally, a transaction processor will want to hedge their bets and preemptively validate according to how likehy they believe it will be that the announcing party solves the next block, or that others will incorporate their announced graphs. Preemptively validating too much could slow down their own ingest process and increase costs, while validating too little serves to increase their orphan risks.

Services and systems that interact with the network forward transactions to the core transaction processing network, and receive updates. The widest scoped of the Overlay Services are generalized transaction submission and proof acquisition systems, facilitating access to information on the current state of tokens. Many overlays can be encapsulated within one another, as they are merely specialized views or windows into what the blockchain keeps account of. A narrowly-focused service might be concerned with tracking product inventories at a small business, but it might make use of a wider-scoped key-value storage overlay for its operations.

Transacting parties, through their specialized applications, utilize their wallets to create transactions. The transactions serve to update and utilize tokens represented within transaction outputs, which can later be spent as they are redeemed or transferred. The rules that govern these transfers are enforced with scripts, and the state of specialized Overlay Services will be driven by these updates. Information can be tracked and made available to Transacting Parties in-band through data embedded within transactions, or out-of-band through external data sources. Out-of-band data can also be privately recorded within salted hashes stored in transactions for tamper-evidence, timestamping, auditability or transparency. The data can still be authenticated and utilized by private Overlay Services, provided they have the correct access rights. Applications represent and display information from Overlay Services to the users, who act on it with new transactions they create.

The transactions flow inwards from the Transacting Parties, through the Overlay Services, and onto the Transaction Processing Network. The network aggregates and assembles transactions into blocks, with state updates about initial graph inclusion, high-order nodes, intermediate proof-of-work, header discovery, intra-block and inter-block reorganization, and double-spend information flowing outwards, back to the Transacting Parties as it is found. In this manner, the Mandala network serves to deliver a secure, resilient, scalable, low-cost blockchain facilitated by specialization, standardization and the division of labor.