Crypto | BlockNet (BLOCK) Mobile Size Whitepaper(2/2)
Abot CORE COMPONENTS
Blockchain services supplement the general-purpose core services to support specific use cases. Since there is no limit to the number of inter-chain services that may be created on the Blocknet, there is no definable limit the number of blockchain services that third parties may build.
Block DX, the first inter-chain dapp on the Blocknet, requires several blockchain services. These shall be introduced, both in order to document them, and to illustrate something of the nature of a blockchain service.
Overview of Block DX Blockchain Services
To function as an exchange requires several services over and above an atomic swap between counterparties. In fact, any exchange (centralized or decentralized) must provide four key functions:
- capital storage
- order broadcast
- order matching
Since Block DX is a decentralized exchange, it follows necessarily that all four of these functions must be decentralized (in addition to some broader aspects pertinent to decentralization, like maintaining a fully open source codebase and virtually anyone being able to list a coin). With atomic swaps, the decentralized exchange service decentralizes both capital storage and settlement a priori. However, atomic swaps do not amount to an exchange on their own; order broadcast and matching must be decentralized in addition. It is these that are supported by blockchain services:
- Order broadcast is decentralized by leveraging the service lookup service, which is entirely peer-to-peer throughout.
- Order matching is performed locally by each trader’s dapp, which are orchestrations of the core components and one or more blockchain components.
The principal design consideration for order broadcast and matching is that, like other peer-to-peer systems, they are naturally vulnerable to DOS (denial-of-service) attacks. In an analogous manner to how Bitcoin functions as an electronic cash system that solves the Byzantine Generals’ problem, a workable solution must amount to a quality-of-service guarantee about orders on the book. Secondly, one of the design considerations in the token ecosystem is how to monetise a service, since in a decentralized ecosystem, if business models are not cryptoeconomically sound, they are not sound at all. What follows is an introductory discussion that frames these problems, and the Blocknet’s solution to them.
Decentralizing An Order Book
Note: the following sections detail the Blocknet’s candidate order system. While other systems are under consideration, the current one is included in order to introduce the design space in which decentralized order systems exist, and to encourage comment and contribution in this new area.
An order book is analogous to a notice board upon which traders may add liquidity by posting bids or asks, and from which other traders may take liquidity by consuming bids or asks. Along with the acts of posting orders to the book or taking them come commitments to settle accounts once a match is made. Now in a decentralized context, an order book becomes essentially a public notice board, upon which anyone is free to post an order, where no central party controls people posting, and whose intentions need not be to trade non-maliciously.
As such, a decentralized order book requires (a) a means of ensuring that only good orders are posted to it (that is, it must prevent order spam), and (b) that if an order is matched, the counterparties are compelled to honour their commitments to settle (that is, it must prevent order-DOS). Now, surprisingly, blockchain is not a good technology to use for an order book, for two reasons: firstly, order books need to operate extremely quickly – at the very least, supporting a realtime user experience – but blockchains require a transaction (generally put, a truth-claim) to be at least several blocks deep in the chain before its truth is sufficiently established. Secondly, since blockchains require mining or staking to establish truth, this opens an opportunity for miners to gain privileged access to order information, and potentially to frontrun, favouring the matching of their orders if they mine the next block. As a result, a different system is required to decentralize orders.
A final novel fact about an order book is that, because orders are commitments to a future settlement act, no funds are sent or risked throughout the order broadcast and matching process, so parties using an order system are exposed to a far lesser degree of risk than that of payments or settlement. This offers an advantage in the design of an order system, as it is not necessary to accept the crippling performance penalty that the use of a blockchain would impart; the system may function successfully while tolerating a certain degree of untruthfulness. As such, the design requirement is, as a minimum standard, to prevent illicit activity from scaling beyond isolated acts. Specifically, the Blocknet solution:
- 1.Supports UTXO verification, that is, that coins offered in an order are spendable.
- 2.Renders order spam unscalable, specifically via a hashcash-style trade fee that has minimal impact upon honest traders but makes spam significantly costly.
- 3.Renders order-DOS unscalable, in the same manner as in (b).
- 4.Renders Service Node collusion economically infeasible (see special properties of Service Nodes).
- 5.Supports partial order matching, enabling several counterparties to consume an order without the abandonment of one trade locking the entire order until the refund transaction becomes spendable. This can supplement a trading strategy that avoids the opportunity cost of a counterparty abandoning a single high value trade by spreading capital over several orders across a price range.
What Do Decentralized Orders Look Like? - Self-Sovereignty
We hold that decentralization, in the context of orders, amounts to preserving self-sovereignty between actors on the decentralized exchange. Decentralization is not a well-understood term, and is frequently conflated with “distribution” and muddled up with notions pertaining to reaching consensus. Decentralization, as Vitalik Buterin explains clearly, is fundamentally about control:a decentralized system places no party under the control of another, except where the matter under concern is a shared resource, in which case all parties participate as equals. Distribution, by contrast, is simply spreading a task or role between several parties, regardless of whether any one party controls this. Finally, consensus between parties strictly pertains to the reaching of agreement about a fact or action, not to whether work is distributed or control decentralized. This does not imply, though, that to decentralize Bitcoin does not require the reaching of consensus about which transactions are legitimate, and that work is not distributed over the edges of its network. These factors are necessary but not sufficient to the decentralization of Bitcoin.
Decentralizing a currency is analogous to decentralizing orders where self-sovereignty is encountered in the former: in the same way that any holder of bitcoins may send coins without third-party control, any trader may add liquidity to the order book or take liquidity from it; in the same way that Bitcoin users may prove to themselves that a given coin was sent at a given time, counterparties may verify the validity of orders and order-acceptance messages on their own. However, the analogy with cryptocurrency ends upon consideration of the fact that orders are offers to send coins, which require a future counterparty to consume them, and involves a matching process. Because a match requires the parties involved to mutually sign an order-acceptance message, and because no other entities need be required to establish that an order is matched, peers on a network may determine and discover the state of orders on a purely self-sovereign basis, without requiring a consensus algorithm (e.g. proof-of-work).
We propose an entirely self-sovereign order system design, involving three parties. Below is a cursory overview, which shall be developed upon as the discussion progresses:
- Before an order is broadcast, a market maker privately sends the order and an anti-spam fee transaction to a Service Node, which can broadcast the latter, spending the coins as a network fee and costing the maker money if it act maliciously. Upon validation of the fee transaction, the Service Node signs the order, which would-be market takers use to validate the order.
- When an order is broadcast, traders may verify, on their own, that (a) the order is backed by real coins, and (b) that it has been signed by a Service Node (signifying that a trade fee has been paid).
- When one or more traders attempt to accept an order, the market-maker adjudicates between these requests (standardly accepting the first valid request) and, on its own, selects its counterparty.
- When a counterparty is selected, it is in the maker’s interest that the counterparty will not DOS the trade, and so it awaits verification by a Service Node that a trade fee was paid.
- Once a Service Node broadcasts a signed acceptance-message, the rest of the market updates its order books by removing the order from the book.
As such, Block DX’s order book functions as a decentralized state machine. The following diagram represents the state machine at a high level (the sections that follows introduce certain details in the diagram):
Separation Of Roles: Service Nodes
The Blocknet’s order system is a three-party system, rather than simply being between the two counterparties to a trade, and this is perhaps surprising. However, it comes as the result of considering the impact to the users experience of precisely when a fee is charged. For example, it would be possible to implement a simple decentralized fee solution if users were required to pay a trade fee prior to placing an order, yet this would result in their being charged even if they were to cancel an order, and even if their counterparty were to abandon a trade. In order to obtain the desired behaviour (that is, for users to only be charged a trade fee if the trade completes or if they cancel), yet simultaneously for fees to be paid upfront, prior to placing an order, a three-party system is implemented. It is the result of separating the incentives to offer liquidity, to take liquidity, to check that one’s counterparty has paid a fee, and to earn trade fees without (a) being tempted to broadcast a trade fee transaction maliciously while (b) not charging trade fees unless an order is accepted. Again, the overriding intention is self-sovereignty, and this is preserved by separating and aligning each party’s incentive to behave in particular ways. This is a complex system, and for simplicity only a few considerations shall be discussed at a time; at this stage in the discussion, the point is merely that Service Nodes are required to charge trade fees without requiring them to be charged when a party cancels before an order is accepted (see the detailed protocol sketch above for the exact roles and sequence in the order system).
Special Properties Of Service Nodes
To support a reliable mechanism for accepting but not spending trade fees (anti-spam and anti-DOS fees) if the party cancels the order before it is accepted, Service Nodes have several novel properties.
1.Limited in Number and Easily Identifiable
Because trading counterparties rely on trade fees as an anti-spam and anti-DOS measure, it is necessary for them to easily identify whether a fee was paid, and this requires to the ability to differentiate orders (and order-acceptance messages) signed by a Service Node from other nodes’ signatures. To achieve this, we require Service Nodes to hold 5000 BLOCK. That way, any trader may easily scan the blockchain for 5000 block UTXOS and compile a list of Service Nodes. Then, if one address containing 5000 BLOCK validates an order’s signature, it has been signed by a Service Node.
2.Expensive to Act Maliciously
Service Nodes shall be required to hold BLOCK for at least 1000 blocks before they may begin earning trade fees and block rewards. If a Service Node acts maliciously – that is, by broadcasting a trade fee when a user cancels an order legitimately – then the trader involved may submit a blacklist proof-claim to the network about the Service Node. To escape the blacklist, the BLOCK would need to be moved to a new address, in which case the Service Node would lose out on very many trade fees and block rewards while waiting 1000 blocks.
3.No Profit from Acting Maliciously
In addition to the high opportunity cost of acting maliciously, a Service Node cannot directly or predictably profit from illicitly spending a trade fee, because trade fees are awarded to the next winning staker, which occurs probabilistically and is thus indeterminate with respect to the winner. As such, Service Nodes have no practical profit motive to act maliciously.
4.Supportive of Cryptocurrencies and Tokens Interoperable with the Blocknet
To validate an order or order acceptance message, Service Nodes are required to verify that the address(es) in the order contain enough coins to fund the order. As such, they have significant hardware requirements, as they are required to maintain full node wallets of each blockchain interoperable with the Blocknet. This requirement further equips Service Nodes to relay messages and transactions for SPV and light nodes where necessary.
5. No Opportunity to Practice Insider Trading
Because any Service Node may sign orders, it is not practicable for a Service Node owner to privilege the orders of any one trader (for example, her own trading node), because if it delays signing the orders (or order-acceptance messages) of others, they may trivially obtain good service from any other Service Node.
As a result of the above properties, traders have (a) a “good reason” to trust the testimony of a Service Node, (b) the ability to inflict income-loss upon a Service Node in the event that it does not act truthfully, of an order of magnitude greater than the loss of a trading fee. (c) As observed above, the low level of risk that traders are exposed to during an order process, and the severe performance penalty that would be imposed to obtain a higher degree of certitude, does not warrant their obtaining a higher degree of certitude about orders.
The Blocknet requires a decentralized system for (a) translating standard order-types on exchanges (market, limit, etc) into basic liquidity-consumption events, and (b) for matching quantities of one coin with quantities of another coin at specified prices. Adopting the decentralized order state machine presented above – that is, where parties adopt self-sovereign roles as either maker or taker – order matching consists of takers requesting to consume liquidity from makers, and in the case of limit orders, the presence of absence of orders up to a certain threshold functioning to determine the trader’s role as a maker or taker.
The behaviour of a market order is as follows: consume orders on the book, beginning from the best-priced order, moving to the next-best-priced, and so forth, until the market order is completely consumed. If the market order consumes all orders on the order book without being completely consumed, then cancel the remaining amount on the order.
The behaviour of a limit order is as follows: if the order is a sell and the price of the order is lower (or if it is a buy and the price of the order is higher) than the highest (lowest) counteroffer on the order book, then consume orders on the book
until either the user's order becomes the lowest (highest) offer, or is completely consumed. If the former, then add the remainder of the trader's order to the order book.
To avoid issues with change on UTXO-based cryptocurrencies – and the resulting need to wait for the change to confirm before the rest of an order can be traded – XBridge shall automate the distribution of trading wallets’ coins into small, regular amounts at separate addresses, in order to maximise the number of outputs that are completely consumed by a counterparty and minimise change to trivial levels. Additionally, a minimum trade size shall be imposed that corresponds to the size of the amounts per address, to prevent the malicious creation of change.
A history of trades between coins is required for charting and other technical analysis tools, and in general for traders to obtain information about a market upon which to make trading decisions. The truthfulness of a trade history is of paramount importance, because considerable advantage over other traders may be gained if one were to fabricate it. As such, the trade history of any given currency pair shall be provided in a “trustless” manner as a Blocknet service.
The solution sketch that follows is somewhat idealised, for reasons of simplicity and in order to present the leading idea rather than the detailed technical solution; a production-ready solution would be considerably more succinct (mostly due to not including the trade history data itself in one of the the atomic swap transactions), and instead would employ a more sophisticated zero-knowledge proof scheme like, for example, bulletproofs.
A “trustless” dataset would require (a) a suitably truthful means of committing trade history data to it, and (b) an equally truthful means of retrieving data from it. The solution is as follows:
A trade history blockchain would be created, and its nodes’ work in establishing consensus would amount to committing trade transaction data from other blockchains to the trade history blockchain. Typical data committed would include:
- coin A
- coin B
- quantity of coin A
- quantity of coin B
- price of coin A : coin B
- time that the first bail-in tx was spent
The data committed must be sufficient for consumers of the data to synthesise into many forms. For example for TradingView charts, the following data would be required:
- period of candle
- start time of candle
- open price
- close price
- and so forth
Commitment Proof Data To commit trade data, nodes on the trade history blockchain must submit proof data:
- coin A
- coin B
- txid of spent bail-in transaction on chain A
- txid of spent bail-in transaction on chain B (or mark if absent)
- txid of spent trade fee transaction for market maker
- txid of spent trade fee transaction for market taker
- timestamps of all transactions
- timestamp for the transaction in which the proof data is submitted
Proof data submitted by a node is then verified by the network by searching the blockchains of the coins involved in a trade and validating the proof data against the the coins’ blockchains. Nodes would also engage in a deduplication exercise similar to mining with respect to the fact that the network must determine the first node to submit proof data for a given trade, and discard proof data submitted by other nodes.
- ・download the trade history blockchain, and thus retrieve the data for free
- ・store in local memory all completed trades – which would require running Block DX continually (in practice, this would only be useful for updating a chart in realtime)
- ・request trade history from a node on the trade history chain, for a fee:
・for a specified coin pair
・over a specified time
To supply trade history to traders, nodes on the trade history blockchain must submit:
- a hash of all txids for coin A, coin B, and trade fees within the time range specified by the trader
- the node’s address
With this data, the trader constructs a simple zero-knowledge proof (though see the note above) of the truthfulness of the data by requesting trade history from many nodes on the trade history blockchain, and verifying that the supplied hashes are identical. If the results are identical, then this amounts to a low probability that the data is untruthful, because the nodes have no good reason to trust one another and are thus not in a strong position to collude maliciously. If the trader wishes to obtain greater certainty about the truthfulness of the data (s)he may request trade history from mode nodes, or download the blockchain herself. Nodes may further monitor each others’ responses to traders and punish dishonest nodes by submitting proofs of how their response is unfaithful to the record in the blockchain; on this basis it is trivial for the network to reach consensus about the dishonesty of a node and blacklist it.
If the trader is satisfied with the response(s) from the trade history nodes, it would pick the first node to supply the hashes, and commence an atomic swap with the following properties:
- ・a bail-in transaction only spendable using
・a private key corresponding to the address the node provided, and
・the trade history data corresponding to the hash provided
- ・(In other words, the trade history data functions as the secret in the atomic swap)
As such, if the trade history node spends the bail-in transaction, then it must reveal the trade history data, and so the trader receives it. Simultaneously, the trade history data cannot be revealed without the trader paying for it.
The current (and simplistic) sketch has a few properties worth noting:
- The size of the requested dataset may be limited by the maximum field length for the secret in the transaction format. This, then, drives revenue for trade history nodes by requiring traders to submit more than one request if they desire trade data over a longer timeframe.
- The fee per dataset may be dynamically adjusted against the trade volume, since greater volume per unit time would reduce the time span of a dataset of a certain maximum size.
- Mild obfuscation of trade history data is provided against other traders intercepting the requested trade history data once the trade history node reveals it: because they neither the trading pair nor the timeframe is included in the dataset, it will not be obviously useful to them and would be expensive and complex to synthesise.
- Strong obfuscation of trade history data would be afforded by it being sent encrypted over XChat, and the secret in the atomic swap functioning also as a decryption key for the data. This, however, would require a more sophisticated zero-knowledge proof that the one in this sketch (see above).
The trade history service above appears to be generalisable to provide a workable registry service for inter-chain services. Intuitively, where the trade is not for a coin but for a digital good instead, the commit and lookup phases in blockchain routing remain unchanged. What would be required in addition is for trade history nodes to filter their blockchain’s record of trades for the most recent record in which a chainId appears, and to compile the resulting list of chainIds and their associated serviceIDs. This list would be delivered, instead of trade history, using the protocol in the preceding section.
The following section is a broad outline of the long term course of the project, intended for gauging overall scope, and is not a series of commitments to development milestones. Shorter-term roadmaps, with well-defined milestones, are published as necessary.
- Monolithic client/node
- Decentralized exchange dapp
- Modularise xbridgep2p
- APIs for all modular components
- Support for data payload in exchange protocol
- Easy interoperability between exchange protocol and xchat transport protocol (controlled via your own Dapp)
- Support for further order types: trailing stop, OCO
- Support for leaving orders in book after closing app (orders committed to blockchain)
- Protocol enhancement: derivative market for swaps (p2p margin lending)
- Protocol enhancement: generic derivative markets
For easier maintenance, and in order to retain a single source of truth for low-level documentation, this section has been moved to GitHub.
Forthcoming. See https://github.com/BlocknetDX/blocknet-docs
Infrastructure for a not-yet-existing ecosystem presents some difficulties to the imagination. “What is this for?” is the single most common design-focused question asked, and the correct answer is something like “anything that can benefit from a token ecosystem” – which is most things. For a less abstract answer, here is a short list of use-cases for the Blocknet:
The decentralized exchange of crypto-tokens is in fact a core service of the Blocknet, since it is necessary for the monetisation of any other service.
This, within an easy-to-use dapp UI, is also the Blocknet’s first consumer product, since it fulfils a real need in the crypto-community for decentralized trading technology.
The prevalence of hacks, fraud, failure, and theft from centralized crypto exchanges has resulted in an alarming 1 in 16 Bitcoins being stolen. A workable decentralized exchange will thus provide a vital enabling function in the fledgling token ecosystem for the safe, secure exchange of coins and tokens
Blockchain routing is also a core service of the Blocknet, since inter-chain traffic must be routable to its intended destinations. That said, it is also consumable as a valuable service, which any node may require in order to either deliver or consume an inter-chain service. The Blocknet’s incipient router, XBridge, currently delivers a free service, and this may remain so for the indefinite future.
Whether used as a chat app or as a data transport, inter-chain messaging is an indispensable service for the token ecosystem. As with decentralized exchange and blockchain routing, this is a core Blocknet service, and it goes by the name of “XChat.” It is end-to-end encrypted, peer-to-peer, and may be used for the ultra-secure delivery of digital goods and messages. It is currently a free service, and is (currently) packaged alongside the blockchain router in XBridge.
A mobile app, with its small footprint, would most likely have only one SPV node and its native blockchain token. As such,
- It would consume services, not other coins
- Various blockchain services it consumes shall run Blocknet components
- When the app requests a service, the service shall generate a “secret” which is also a decryption key for the digital goods
- The service shall send data enabling the app to construct a zero-knowledge proof that the goods are legitimate
- The service shall create a bail-in transaction in an atomic swap
- The service shall spend the bail-in transaction and later trade it for another coin, if preferred
- The app thus receives the secret and may consumes the service
A private currency such a ZCash, ZCoin, or Monero may integrate to XBridge, and script the automatic trading of any currency for the private currency and back again into the original currency. Since the decentralized exchange does not require any third party to be trusted with users’ data, and since the atomic swap involves no counterparty risk, the result is a nearly perfectly private mixing service.
A marketplace app would typically require the following services: (a) customer reputation and info, (b) payment processing, (c) image storage, (d) item listings. A microservices architecture is advisable for the reasons given above, gaining the advantages of utilising multiple blockchains. Thus, one chain may store encrypted customer info (see item 13 on this list), use the XBridge to accept payments in any cryptocurrency, store images on a server, and use a third chain and in-wallet code for the item listings and UI elements. The result is a scalable, composable set of services that are easier to bugfix, upgrade, or replace.
Using the decentralized exchange, any Ethereum contract may be supplied with "gas" in other coins.
A stablecoin may maintain its peg by exploiting the fact that trade records on a decentralized exchange are on-chain. As such, a provably truthful dataset is available for determining whether to mint or burn coins (or freeze and unfreeze them) in order to maintain a peg.
A personal information service may records encrypted personal metadata on a given blockchain equipped with a revocable permissioning system. Users thus acquire self-sovereignty over their personal information. From this point, one may integrate this blockchain to any website or app requiring sign-in, or users can voluntarily sell their metadata to advertisers for micropayments, or it can support passport/identity systems. Emerging technologies positioned to exploit this use case are Bitnation and Microsoft’s Coco Framework.
Blocknet infrastructure is well-suited to function as a “supply chain 2.0” backbone. Parties typically find themselves on different blockchains, with a need to interoperate, and may do so by exploiting Blocknet services. Multichain apps will thus be able to read data from several chains, whether they are specialized in shipping data like Bill of Lading, product manufacturing data like Bill of Material, financial dat, and so forth. By comparing metadata from several sources, the Blocknet could empower companies to limit attack vectors like invoice spoofing and certification counterfeiting.
Some perennial IoT security issues may be solved by exploiting blockchain technology, and then interoperating between thousands of blockchains over the Blocknet. Diverse opportunities for granular monetisation present themselves too: for example, one may accomplish transaction batching on several chains at once using SPV wallets. The data stream may thus be tokenized, and nodes may be incentivised to engage in pattern finding in a company’s big data.
A mobile app may earns its users tokens by screening ads delivered to the app as a Blocknet service. Tokens could then be used to power inter-chain service consumption for the app, delivering a “free” service for the user, but a monetised one for the service providers.
A blockchain-based storage solution, such a Storj, may have its user base significantly enlarged and monetized via inter-chain service delivery.
Anyone may offer token sale over a decentralized exchange, with no permission required.
Crypto projects are typically launched as a big crowdsourced business case (ICO), where a budget is negotiated with the market. However, the actual account balance fluctuates as the price of the cryptocurrency the crowdsourcing was conducted in. changes in value. Using the Blocknet, developers may manage the distribution of tokens and accounts across chains. Furthermore, with the use of a smart contract, disbursements and investments in other coins may be managed and, in general, the project’s business plan coded and automatically executed by the contract with perfect transparency.
The Blocknet’s simple API-based integration enables interoperability either directly or indirectly with consortium-type and private blockchains, like those of ORACLE and SAP.
The Blocknet’s inter-chain infrastructure shall function increasingly over time to create an “internet of value” that is inherently truthful, transparent, and fairly available. As companies’ general- and sub-ledgers come gradually to interface with other companies’ ledgers through blockchains, the resulting network of blockchains will become a full representation of value streams and of a given system’s value. This enables advanced and deep awareness of value across entire systems, with correspondingly powerful and far-reaching consequences for the financial system.