Crypto | BlockNet (BLOCK) Mobile Size Whitepaper(1/2)
The Blocknet is infrastructure for the coming “inter-blockchain era,” an emerging technology epoch characterised primarily by the superseding of the current API ecosystem with a decentralized and intrinsically monetized “token ecosystem.”
This document is intended for both a nontechnical and a developer audience, provided the reader has at least a foundational understanding of blockchain technology. The Blocknet’s design and architecture are introduced in a largely nontechnical way, with the aid of diagrams, and through a step-by-step exposition of what inter-chain services are and thus what an inter-chain infrastructure service must provide at a minimum. With increasing frequency as the document progresses, the discussion turns from what inter-chain services would be like to specifications of what the Blocknet is. By combining matters of design with those of implementation and integration, the intended result is a systematic design specification of the Blocknet.
We believe that there is no better way to design solutions than to communicate and to gain insights on our work from multiple perspectives. We also believe that by not keeping our work private, we stand to gain enormously from people’s engagement with it and with our code. Thirdly, in an infrastructural project, it is of paramount importance to engage those who would use and build upon our technology.
Some may be concerned about the perceived risk that competitors could copy our work and gain the advantage, especially because our design is both first-to-market and has yet to achieve major traction. Be that as it may, the combined insights of the crypto and enterprise architecture communities are a resource that we cannot afford to be isolated from, and so the risk-reward ratio leaves us unconcerned.
The Blocknet is neither a company nor an exclusive team, it is infrastructure, and we believe that infrastructure ought to be publicly owned and freely available to all.
This document is currently a draft and not a final design. In fact, the notion of a final design has no clear place in a project that practices continuous development. We welcome contributions and discussion to this document.
The Blocknet’s code is open source, and anyone may contribute to the Blocknet project.
A project such as this stands to benefit the most when a variety of perspectives and skills come to bear on its design and implementation. We welcome collaboration of every variety.
To contact the Blocknet, email email@example.com.
The Blocknet is infrastructure for the coming “inter-blockchain era,” an emerging technology epoch characterised primarily by the superseding of the current API ecosystem with a decentralized and intrinsically monetized “token ecosystem.” This will occur when its enabling technologies (specifically, smart contracts and “dapps”) mature to the point of possessing practical inter-blockchain interoperability. At the time of writing, the Blocknet is the technological leader in the provision of inter-chain infrastructure for use by dapps and smart contracts.
We believe that the emergence of the inter-blockchain era will have disruptive implications for two sectors, that of software-as-a-service, and practical blockchain usability.
From the perspective of software-as-a-service (SaaS), the token ecosystem embodies two fundamental advancements: (a) the comparatively frictionless monetisation of digital services, and (b) the leveraging of the unique robustness, decentralization, and security properties of blockchain technology.
From the perspective of blockchain technology, if blockchains are to achieve their true potential, then broad, generic interoperability between blockchain services is required. Without inter-chain interoperability, blockchain-based services will (a) either deliver services only within the confines of the limited customer base that runs its nodes, or sacrifice the unique security properties of blockchains in delivering to centralized entities, and (b) face enduring problems with chain bloat and, relatedly, the market-related pressure to build further features onto a single chain.
By creating an “internet of blockchains,” the Blocknet is positioned to enable the frictionless monetisation of APIs, and in doing so, to empower blockchain technology by converting its thousands of isolated chains into a token ecosystem.
Traditional internet-based services are faced with perennial insecurity in their technology stack. Furthermore, they typically require the centralization of functions and data, placing a high trust-burden upon their customers. In contrast, blockchain technologies enable one to exploit cryptographic proofs to deliver “trustless” services, where each participating entity may prove to itself the certitude of a given outcome, and thus radically reduce the amount of trust required to do business with another party. This systematically enlarges the range of ways of doing business, enables many new business models, and may provide clearly defined security guarantees, lowering costs and better protecting brand value.
Yet blockchains cannot immediately achieve their true potential, for the primary reason that they are not interoperable. There are thousands of blockchains in existence, yet they currently function like LANs disconnected from the internet, and have yet to create the circumstances that will foster the era-defining disruption that generic interconnectivity brings – on a scale similar to how the internet enabled the emergence of Facebook and Google.
The Blocknet is foundational infrastructure for the token ecosystem. It provides true peer-to-peer interoperability between nodes on different blockchains, in order to enable the following:
- The delivery of potentially any kind of digital service from a node on any blockchain to another.
- The ability for any given blockchain service to function not as an “appcoin” but as a “protocol service,” that is, to be consumable by any other dapp on any blockchain, for open-ended purposes, instead of only the purposes of its creators’ dapp, greatly enlarging the service’s market reach and revenue stream.
- The ability for smart contracts’ tokens to function not merely to monetise “dapps” but to be “protocol tokens,” logically placing them at a layer lower in the technology stack, where their potential utility is at a greater order of magnitude. Additionally, services’ code quality may benefit from a broad contributor-base of developers from diverse communities, exploit their combined learnings, prevent chain bloat and code duplication, save labour-time, and deliver services to the entire blockchain-consuming market, instead of just the set of users of its blockchain.
- The ability for dapps to be simple orchestrations of inter-chain services instead of difficult hand-coded creations from the ground up. The primary development tasks thus become API integrations, not the difficult and highly specialised role of coding new and “bulletproof” smart contracts.
- The building of dapps with a microservices architecture, where each blockchain may deliver a single service, integrated with many others in a modular fashion, providing simpler component design, easier bug fixing, and easier upgrading.
- The ability to effectively bypass the (currently-difficult) matter of choosing which blockchain to build upon – and not only at the start of a project, but at later points in its lifecycle, when various microservices may become better-implemented on a different blockchain.
- The monetisation of inter-chain and multi-chain services, using their intrinsic tokens of value.
- The full exploitation of new, cryptoeconomically-driven business models ushered in by blockchain technology. For example, businesses may extract value from a “better than free” model, from monetary policy directly (ICOs, transaction fees, deflationary economics, block rewards, and superblock self-funding systems), and from a marketplace for its monetized APIs.
The Blocknet shall achieve the above through an architectural and protocol-based approach, the documentation of which is the subject of this paper.
The following features shall be designed for, in descending order of priority:
First and foremost, the Blocknet is inter-blockchain infrastructure. As such, its most direct design objective shall be interoperability with an overwhelming majority of existing and future blockchain implementations. Additionally, it shall be interoperable with centralized entities in order to make traditional server-based services available within the token ecosystem.
To be decentralized is, essentially, for no one entity to exercise control over other entities in a system. For example, perhaps Bitcoin’s major achievement is – in broad terms – the decentralization of money, in which no one entity controls (a) the currency’s value, (b) the transferral of funds, (c) the keeping of records of account, and (d) its monetary policy.
Yet Bitcoin currently exists in an ecosystem that is largely centralized, nullifying many of its benefits in practice. It is of little value to offer a centralized ecosystem for the delivery of decentralized services, since (a) this exists already, in the form of the API ecosystem, and (b) the property of interest, namely decentralization, would largely be lost during service-delivery. For example, if one buys Bitcoin using a centralized exchange, the purchase is not “trustless” because one must trust the exchange, and the purchase is subject to all the usual friction of traditional payment infrastructure (bank fees and delays, payment gateway fees, visa and mastercard fees, fraud risk, KYC requirements, the requirement to trust many intermediaries with one’s money and personal information, and so forth). Hence, in order for Bitcoin and every other decentralized technology to achieve its potential, a decentralized ecosystem is required, where entities may do business without compromise to the technologies’ disruptive power.
Decentralized and monetary services characteristically require high security and high determinacy of operation at a level comparable to aeronautical applications, because (a) it is not generally possible to alter or take offline a service that runs on the edges of its network, on its users’ devices, and (b) if money were found to be stealable in a system not subject to central rectification, then it would very quickly lose most of its value. For these reasons, the Blocknet requires the highest level of security and determinacy of operation.
In the context of blockchains, a frequent and desirable consequence of decentralization is that it is not necessary to trust a counterparty to act honestly over the course of a transaction. For example, with Bitcoin, one does not need to trust a middleman to transfer funds or a recipient to report honestly on whether the payment was received or what its amount is, since no middleman is involved and counterparties may independently verify a payment’s status with an extremely high degree of confidence.
In the case of inter-chain service delivery, an equal degree of “trustlessness” is required when payments for services are made between blockchains, in order that the service may be rendered and paid for without requiring participants to act honestly, thus preserving this unique feature of blockchain-based payments in an inter-chain context.
To maximize interoperability and to reduce friction, integration to the Blocknet and access to the token ecosystem shall not require modification of stock wallets or nodes. Note that consumption of some third party service which leverages the Blocknet for its delivery may require coding, but the use of the Blocknet itself shall not.
To maximize security and to foster an open, internet-style ecosystem, integration to the Blocknet and access to the token ecosystem shall not require the mediation of any central entity (even us). To deliver or consume services over the Blocknet, consumers shall not be required to (a) use the Blocknet’s blockchain, (b) use any specific service, or (c) use any service that has a centralizing effect. (Here “centralizing” is taken to denote a range of scenarios, from control by a central agent to a sidechains-style centralization of networks around its network. The latter we describe as “inter-chain centralized.”)
Note that consumption of some third party service delivered over the Blocknet may require the mediation of some central party, but the use of the Blocknet itself shall not.
As far as is possible, the Blocknet shall be built with composability and modularity in mind, in the same pattern in which inter-chain microservices are envisaged above. Specifically, the key principles of microservice design is to maximise composability while being mindful of which services will always be consumed together, in order to avoid building a “distributed monolith.” These are preserved unchanged in the context of a token ecosystem.
In the token ecosystem, an additional key principle is added to the principle of composability: that a service be intrinsically monetizable. If not, then we suggest it be bundled into a monetizable service’s API, or else the people who would run the service’s nodes may lack a reason to, since they’d not be able to derive a revenue stream from it.
Furthermore, a service’s revenue stream is required to be secured via some trustless protocol or via cryptoeconomic incentives, or else value is not likely to be captured. Monetisability is as much a question of whether a consumer of your service will be willing to pay for it as it is a question of whether they are unable to forcibly consume it for free.
The Blocknet shall monetise its core services where feasible, offer others for free, and shall provide various means by which services delivered over the Blocknet may be monetized securely.
Several scenarios, from mobile apps to embedded IoT devices in the insurance, health, supply chain, agriculture, automotive telematics and security industries, stand to leverage the token ecosystem.1Many of the use-cases we expect to emerge will require dapps with a very light footprint, which would thus be unable to host even a single blockchain. The Blocknet shall provide access to the token ecosystem for such devices, in order that they may harness blockchain-specific security properties which we feel are mission-critical to reducing the attack surface of IoT services. Specifically, the Blocknet shall enable applications with a small footprint to consume (and pay for) inter-chain services without hosting a blockchain locally.
General purpose inter-blockchain interoperability is achieved by the integration of three core components, which together function to deliver あ core services, accompanied by any number of blockchain services and blockchain components. These serve to enable the building of an unlimited number of inter-blockchain services – a token ecosystem – all of which may be orchestrated into inter-chain applications.
To aid the reader in this novel territory, these shall be introduced with the help of a series of diagrams, which articulate the relations between components and services. The diagrams shall progress from one to the next as follows:
The components shall be introduced first, followed by the services. Prior to this though, the general nature of inter-chain architecture shall be introduced.
In general, inter-blockchain architecture will always involve at least two blockchain networks, and some additional entity or function to deliver interoperability between them. Since blockchain networks are decentralized and distributed, the interoperability component(s) ought not be placed in some central location; to preserve decentralization, they are required to either run on, or locally interface with, nodes at the edge of each network.
Various projects have proposed solutions of the following kinds:
- traditional technology: a centralized intermediary (e.g. Poloniex.com)
- maximalists: a decentralized network which functions, as a logically centralized intermediary (e.g. Bitcoin in a sidechains context)
- proprietary code (i.e. wallets, smart contracts, or bolt-ons to wallets) that achieve blockchain interoperability only between nodes running this code (i.e. BTCrelay)
- a walled gardens: inter-chain protocols only between instances of some custom blockchain, which locks developers into building upon it (e.g. Aion).
None of the above varieties of inter-chain technology are both generic and decentralized. That is, they either do not provide support for an open-ended variety of services (including those on existing blockchains), or they fail to provide such support without centralizing control in a way that betrays a given service’s dependency upon being decentralized in one respect or another.
As per the Blocknet’s design objectives, a satisfactory solution must be both generic and decentralized. We approach this by “first principles,” that is, by remaining faithful to the nature of the inter-chain scenario itself.
1.Distributed Network Architecture
Firstly, of unambiguous importance is that any inter-chain component(s) must exist on the edges of the networks they interoperate with. This distributes the service across each blockchain network that delivers or consumes services. Additionally though, the inter-chain components must deliver services from the edges of their own network too, without requiring central action, or else it will function as yet another centralized intermediary.
Secondly and relatedly, an act of delivering or consuming an inter-chain service must be self-sovereign, that is, not subject to control by a third party. Architecturally speaking (that is, apart from protocol design), the most direct and secure means to achieve this is for nodes of the inter-chain service component and either the network consuming or delivering it, or both, to exist on the same local machine. The extent to which this is necessary – and to which it impacts the footprint of an inter-chain service – will vary, ranging from a requirement to run full nodes, to SPV nodes, to merely signing transactions, through to, at a minimum, querying a blockchain explorer website or other centralized oracle in low-security applications. The latter shall be considered a limit-case for the applicability of the term “inter-chain.”
As such, the full range of local architecture requirements is evinced. In every case other than the limit case, some manner of direct participation in both a delivery and a consumption network is required for each actor to participate in a decentralized fashion. This may be graphically indicated by iterating upon the previous diagram:
3. No Blockchain Lock-In
While every inter-chain service must be delivered from nodes on some chain, inter-chain infrastructure must not limit which blockchain a given service may run upon, or else all that is achieved is essentially a kind of distributed client-server model, which is in fact the default architecture for centralized applications today. For example, Blockstream’s implementation of sidechains would require that every user interact with the Bitcoin blockchain in order to consume any other chain’s service. We term this pitfall “inter-chain centralization.” To avoid it, a true internet of blockchains – and one that can support a token ecosystem – must enable services to be delivered or consumed from any blockchain.
This chain-agnostic notion motivates for the careful minimising of integration requirements and app footprint. For example, if the Blocknet were to require that every consumer of an inter-chain service maintain a copy of the Blocknet’s blockchain, possibly in addition to the service provider’s blockchain, then its usefulness would be rather limited and its user-friction be very high.
This aspect of inter-chain infrastructure design will come to bear chiefly upon the monetized delivery of a service, since, firstly, on a peer-to-peer network, actors are untrusted and it is necessary for payment and service-delivery to be atomic. Secondly, a node must be paid in its native token by a node with a different native token, and so they will have to be exchanged, and decentralized exchange requires a high degree of security and code quality. Yet if it is required that two or even three blockchains are downloaded and maintained in order to consume the service, it is unlikely that it will see widespread adoption. Hence, the Blocknet shall provide means to avoid this.
The above considerations yield three guiding principles for the design of the Blocknet’s components:
- 1.Inter-chain infrastructural services must run on the edges of both their network(s) and any service-delivery and consumption networks.
- 2.Architecturally speaking, service-decentralization is most easily achieved by running components required for either the delivery or the consumption of a service on the same local machine.
- 3.Inter-chain infrastructural services must limit their integration requirements and footprint where possible.
The Blocknet comprises three core components, which function together as the foundation of a general-purpose inter-chain service infrastructure:
- ①XBridge, an inter-chain network overlay
- ②XName, a blockchain router
- ③XChat, a p2p data transport
These three components are defined as “core” because, intuitively, any inter-chain interoperability solution will necessarily require some means of networking between nodes on different underlying networks, some means by which nodes may discover where to route service requests, and some protocol for p2p communication once a suitable node is located.
To aid the reader in remembering and visualising the complex of components and services in the Blocknet, a diagram shall be constructed progressively as elements are introduced. The following diagram shows just the Blocknet’s three core components.
The Blocknet features XBridge, a serverless DHT-based peer-to-peer network. On a given local machine, nodes on this network are integrated with nodes on other networks, making our network an inter-chain network overlay. This enables lookup, location, and broadcast between nodes on any blockchain network.
For technical documentation, refer to the Technical Specification section.
- Current: the network overlay code is implemented in both XBridgep2p.exe and in the Blocknet wallet. It is not monetized.
- Future: this may be modularised in the codebase, though it is unlikely to be released as a standalone application, since it will interoperate with other components to deliver core services.
An ecosystem of inter-chain services requires a means of routing messages to the correct blockchain, which, in the Blocknet, shall be achieved via an inter-chain address system. Blockchain routing is in its elementary stages and requires exploration and agreement by the broader crypto community, but, fundamentally, it requires an inter-chain standard for designating blockchains such as Uport’s MNID, a way of committing routing data to a registry, and a lookup function. A key outstanding question is the optimal price-to-truthfulness ratio of routing results. For example, services may benefit most from a free registry service and tolerate a certain degree of bad lookup results by eliminating the possibility of dishonesty after lookup, immediately prior to payment and delivery. Alternatively, some services may require provably truthful lookup results and would tolerate a microfee for this. XName shall take an agnostic approach to registry service design, and its mature solution shall provide for diverse integrators’ needs if necessary - including the possibility of the emergence of a competitive marketplace for registry services.
As such, a logical router design direction is to offload matters of the truthfulness and cost of (a) lookup and (b) the committing of routing data to dedicated registry services – including lookup of the chainIds of registry services. XName’s function would thus be to invoke registry services’ APIs and, after service delivery is completed, to store locally a cache of routing results.
To ameliorate circularity (that is, having to look up a registry service before one can look a service up) on initial launch, nodes may bootstrap themselves either (a) querying a hardcoded chainId for a provably truthful registry service, or (b) by querying their peers over XBridge with a dedicated get Registry Service call, and then querying each registry service returned, thus exploiting whatever truthfulness guarantees each service may provide in order to build a truthful local list of registry services (and other inter-chain services). To return to the question of how to commit and look up inter-chain services, see both the Service Lookup and the Registry Service sections.
For technical documentation, refer to the Technical Specification section.
- Current: the blockchain router is implemented in both XBridgep2p.exe and in the Blocknet wallet, along with the other core services.
- Future: this component is likely to always interoperate with other components to deliver Core Services, and so will not necessarily be made deployable independently. However, it may be, if sufficient progress is made to render blockchain routing monetizable, since its monetisation will enable the service to reflect its own running costs, to allow competition between routing services, and to incentivise the technological advancement of the service. If monetized, the router component may additionally integrate with other components on their own blockchain network.
The delivery of digital services requires a means of sending and receiving both messages and the service’s payload itself. As such, the Blocknet features XChat, an end-to-end-encrypted, peer-to-peer messaging module that supports both one-to-one messages and group messages. (Broadcast messages are already supported by XBridge: the Inter-Chain Network Overlay.)
The requirements for communication and for digital service delivery vary with the nature of the service. Privacy, bandwidth, latency, persistence, and the absence or presence of intermediaries are all variables. As such, this service may mature into several data transport technologies. At this very early stage though, a supremely private, fast, peer-to-peer solution appears to be adequate.
Technical documentation is available in the Technical Specification section.
- Current: the data transport is implemented in both XBridgep2p.exe and in the Blocknet wallet along with the other core services.
- Future: this may be modularised in the codebase, and if it is monetizable as a standalone application, may be released as such.
Monetizable inter-chain services require three core infrastructural services:
- Service Lookup: a way of discovering peers to deliver or consume a service
- Inter-Chain Messaging: a way of delivering a digital service
- Decentralized Exchange: a way of monetising the delivery of the service
These services are orchestrations of the Core Components, and as such may be represented on the apexes of the previous diagram’s triangle, as follows:
Inter-chain service lookup is an orchestration of the XBridge, XName, and XChat components, and invokes any given
registry of inter-chain services on the Blocknet. It may be abstracted into an API façade as the Blocknet matures.
Like the traditional internet, parties need to look up and locate each other in order to interoperate. Thus, an analogue of the Domain Name System (DNS) is required. Unlike the traditional internet though, services are delivered peer-to-peer and generally by any node on a network, rather than from servers addressable from a single IP address, and so in order to request a service it will characteristically only be required to locate any node on a given blockchain network. Hence, “chain codes” are the primary requirement, along with other secondary properties.
It is assumed that services shall generally be delivered to a specific node and to that node only.
A significant feature of a registry service over a peer-to-peer network of untrusted nodes is that, unlike circumstances in which the service provider may reasonably be trusted, anyone with any intention (malicious or otherwise) may provide it. Depending on the design strategy, either the truthfulness of the data returned from service lookup shall not be
guaranteed, and therefore guarantees as to the service’s integrity must be provided at a later stage, or service lookup must be conducted in such a way as to cryptographically guarantee the truthfulness of the data regardless of the intentions of the node providing the service. The Blocknet’s design is intended to be agnostic as to which approach to registry design is taken.
On the former design assumption, the typical steps for service lookup are:
- Find peers on XBridge
- Retrieve a service’s chainId and serviceList over XName
- Query peers over XBridge to find a peer on the chain designated by the chainId
- Switch to XChat; get a list of the services the specific peer supports
- Request a service (and proceed to construct a proof of the truthfulness of the service)
On the latter design assumption, service lookup may be trivially accomplished (that is, with no original contribution from this project) by employing a blockchain consensus algorithm (e.g. proof-of-work) and for the node looking up a service to host locally a blockchain containing the chainId data and simply query it for free. But this imposes a significant storage and uptime burden upon a user, and so is not expected to be a typical way of using the Blocknet. Outside of a context where users maintain a service registry blockchain, SPV nodes, as described in the original Bitcoin whitepaper, may be employed. For greater scalability and a smaller app footprint, as of the time of writing, alternative proof systems are being explored. See the Trade History and Registry Service sections for design patterns.
The above steps imply the following high-level architecture:
Technical documentation is available in the Technical Specification section.
- Current: Service lookup is currently implemented either as part of XBridgep2p.exe or embedded into the Blocknet wallet. At the Blocknet’s current stage of development, the only application implemented is a decentralized exchange, which requires only that nodes filter by currency pair. As such, a more general-purpose lookup service remains to be built.
- Future: Upon suitable exploration and consensus by those in the blockchain ecosystem, development of a generic lookup service is planned. Furthermore, to simplify consumers’ integration with the underlying components, service lookup may become embodied in an API façade. Whether this will be a single façade for all the core services, or a distinct façade specifically for lookup, is probably a function of time, maturity, and consumer demand.
Inter-chain messaging is an orchestration of XBridge and XChat, and is a matter of a service provider and consumer locating one another, communicating, and the service being delivered.
This service is specified under the assumption that consumers shall actively find services, while service providers shall passively be locatable.
On public peer-to-peer networks it cannot be assumed that every entity presenting itself as a service provider or consumer will act in good faith, and so for most services, it will be necessary to both prove that the service’s payload is legitimate prior to making payment, and that the consumer cannot receive it without also making payment. In other words, services must function both trustlesslyand atomically.
A planned way to achieve “trustlessness” in this context is through the use of a zero-knowledge proof system. As the notes on BIP-0199 state, “[v]arious practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See pay-to-sudoku for a concrete example of such a protocol.)“ Note, for the sake of clarity, that a simple digital signature scheme set up to prove that the service provider is in fact who the consumer thinks it is constitutes a zero-knowledge proof, in the sense that the service provider’s private key is not revealed, yet the consumer may prove to itself the identity of the service provider. The actual proof-schemes implemented on one service or another can be expected to vary with the particulars of what needs to be proved for the “trustless” delivery of the service.
Atomicity in this context is achieved through decentralized exchange, in the following section.
Typical steps in the inter-chain messaging service are:
- 1.Find a service over the network overlay and request a service, as per the preceding section
- 2.Over XChat, the service provider supplies materials for a zero-knowledge proof of the payload's legitimacy – that is, for creating a proof over some set of assertions that sufficiently ensures the payload’s legitimacy (see the Trade History section for an elementary example)
- 3.The consumer accepts the service
- 4.The service provider proceeds to the decentralized exchange service to commence service-delivery
In the interest of minimising app footprints or for simplifying consumption, inter-chain messaging may demand a distinct API façade. Use-cases where this seems pertinent are where services are free and where chain lookup can be hardcoded, for example, a decentralized chat app.
The above implies the following high-level architecture:
- Current: Developers may (a) embed XChat into their applications, and (b) exploit the network overlay, either through the XBridge standalone application or in its embedded form in the Blocknet wallet.
- Future: Components shall be modularised and APIs written, and in addition, potentially an API façade abstracting and orchestrating the two components into an explicitly defined service.
Decentralized exchange is a trustless, atomic means of exchanging currency for either another currency or for a service. It is an orchestration of XBridge, XChat and at least two wallets or blockchain nodes in a generalised implementation of Noel Tiernan’s atomic exchange protocol. This protocol exploits the creation of a secret, the knowledge of which is required for the spending of funds, and which cannot fail to be disclosed when funds are spent. Thus, if its creator spends a counterparty’s funds, then the counterparty possesses the secret and may spend the creator’s funds in return.
- Note: the decentralized exchange service is distinct from the decentralized exchange application, Block DX, which consumes this service in additional to several blockchain services.
The first version of the protocol was shown to be vulnerable to a malleability-based extortion attack, and later rectified, in the Bitcoin-and-clones ecosystem, with the introduction of the opcode OPCHECKLOCKTIMEVERIFY. A design utilising the latter is detailed in Kay Kurokawa’s blog on the subject. Finally, to support not only atomic swaps of cryptocurrencies and tokens, but also any digital payload, we add to this protocol the use of a decryption key or secure hash function as the secret. As such, the revealing of the secret enables the immediate consumption of a previously-supplied encrypted digital good, or the verification of some truth-claim. This, in conjunction with the use of zero-knowledge proofs in the preceding section to allow a consumer to verify the credibility of a digital good in advance of receiving it, achieves the trustless consumption of monetised goods and services. As such, it is a general monetised service protocol.
Conceptually, the protocol steps are as follows:
- 1.The service provider creates either a decryption key (for digital goods), a digital signature or cryptographic hash of some file (for truth-claim verification), or a random number (for coin trading), and uses it as the protocol’s secret.
- 2.The service provider creates a “bail-in” transaction with the rule “this transaction may either be spent by the consumer if (s)he supplies the secret, or if both the consumer and service provider sign the transaction.” (If a digital good is being offered, rather than coins, then only a quantity of coins sufficient to cover a network fee is required.)
- 3.The service provider creates a fallback mechanism in the form of a second, “refund” transaction, with the rule “send the bail-in transaction’s output to the service provider’s address, but not earlier than (x) amount of time from now.”
- 4.The service provider requests that the consumer sign the refund transaction, in order to meet the second requirement in the bail-in transaction that it may be redeemed if both consumer and service provider sign it.
- 5.The consumer signs the refund transaction and returns it to the service provider.
Note: this enables the service provider to reclaim its coins (if any) after the specified time period, in the event that the consumer abandons the exchange or another factor causes it to fail to complete.
- 6.The service provider broadcasts the exchange transaction. Note: the consumer may now “spend” this transaction if (s)he is given the secret.
7.The consumer creates her own “bail-in” transaction, as in step 2, for coins on her own blockchain.
Note: this transaction requires the same secret to be revealed in order for it to be spent – which only the service provider is in possession of at this stage.
- 8.The consumer creates her own “refund” transaction, as in step 3.
- 9.The consumer requests that the service provider sign her refund transaction, as in step 4.
- 10.The service provider signs the refund transaction and returns it to the consumer.
a.Note: this enables the consumer to reclaim her coins in the event that the service provider fails to redeem them, since otherwise the secret would not be revealed to the consumer and she would thus not be able to consume the service or receive coins in a trade.
- 11.The consumer broadcasts her bail-in transaction
a.Note: the service provider may now spend the consumer’s coins, since it possesses the secret.
b.Note: by spending the consumer’s coins, the service provider reveals the secret publicly, and thus the consumer may now consume the service.
c.Note: if the service provider would prefer to cancel the exchange, it may wait until time x in step 3 and broadcast its refund transaction.
12.The service provider spends the consumer’s exchange transaction, revealing the secret.
a. Note: if the service provider fails to spend her bail-in transaction, then the consumer may broadcast her refund transaction and receive the coins back after the specified time period.
b.Note: the service provider must spend the consumer’s bail-in transaction within the time period specified in her refund transaction, or else the consumer is free to refund herself.
13. The consumer uses the secret either to spend the service provider’s bail-in transaction, or to decrypt a file, or to verify a fact.
a.Note: in the case of a coin trade, the consumer must spend the service provider’s exchange transaction within the time period specified in its refund transaction, or else the service provider is free to refund itself.
Note that the above protocol shall include additional supplementary steps in which Service Nodes are updated as to the state of the atomic swap, in order for SPV nodes and “light” clients, which depend upon their peers to relay transactions and messages, to be reliably updated.
As implemented in the Blocknet’s components, decentralized exchange typically involves the following steps:
- After the consumer accepts a service as per the steps in the Inter-Chain Messaging section, the service provider takes protocol steps 1-3, and then, over XChat, step 4
- The consumer takes protocol step 5 over XChat
- The service provider takes protocol step 6 over its native blockchain network
- The consumer takes protocol steps 7-8, and then, over XChat, step 9
- The service provider takes protocol step 10 over XChat
- The consumer and service provider take protocol steps 11-13 over their respective native blockchain networks
Note that these steps only concern the decentralized exchange service. The decentralized exchange application, Block DX, like most applications, requires several additional (that is, non-core) services in order to function as an exchange, specifically, order broadcast, order matching, anti-spam measures, anti-DOS measures, and trade fee collection.
The above steps imply the following relations between components on a local machine:
- Current: The decentralized exchange service is embedded in the Blocknet wallet, and in the standalone XBridgep2p.exe (however, development will resume on the latter at a later stage). An API is available, concurrently supporting the decentralized exchange application.
- Future: The service shall be abstracted from the various blockchain services that Block DX consumes, and an API façade built to orchestrate XChat and the blockchain services.
On a given local machine, the three core services introduced in the preceding section may interact with any one or a combination of the following component-types, which may be on several blockchains:
- Full Nodes: “regular” full-featured nodes and wallets
- Light Nodes: SPV nodes and those which are even lighter (e.g. those that merely sign transactions)
- Service Nodes: nodes with special features to provide a given service over and above regular blockchain work
These component types are generally third-party integrations not built or maintained by the Blocknet. Nonetheless, they provide a necessary function in the Blocknet, namely interacting with their native blockchains, without which the Blocknet would not achieve interoperability without duplicating it on its own components – which would be an untenably inefficient approach.
The three core components and services, plus any additional node-types consuming or delivering an inter-chain service, are thus representable as follows:
<a href="https://pocket-wp.com/cryptoassets/BLOCK/explanations/67b8342ae5deea90"> NEXT