Crypto | BlockNet Whitepaper(1/2)
edit 編集

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 contact@blocknet.co.



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:

1. Interoperability

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.

2. Decentralization

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.

3. Security

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.

4. Trustless Service Delivery

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.

5. Simple Integration (No Coding Required)

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.

6. Decentralized Integration

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.

7. Composability

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.

8. Monetisability

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.

9. Mobility and Small Footprints

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.

What Does Inter-Chain Architecture Look Like?

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)
  • 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.

2.Decentralized Actors

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.

Message Steps

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.

Context Diagram

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.

Message Steps

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.

Context Diagram

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.

Preceding Work

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.

Protocol Steps

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.

Message Steps

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.

Context Diagram

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


BlockNet (BLOCK)に関連する他の情報に触れてみる


暗号資産(暗号通貨, 仮想通貨)やブロックチェーンは理解が難しく、また一次情報の多くはPCに最適化されている状況にあります。PocketWPでは、下記の3点のアプローチによってその問題を解決しようとしています。
  • ・SmartPhoneFirst - スマホで最適化したスライド/UI
  • ・Stockable - 流れてしまいがちな情報を蓄積し、共有できる
  • ・Followable - 追いかけるべき情報源がわかる
将来的には共同で編集できる仕組みなども設計中です。 暗号資産・暗号通貨の価値を広げるには、良質な情報を読みやすく噛み砕くことが必要だと思っています。 よろしければご意見をこちらからお寄せください (お問い合わせフォーム)
運営者情報① : IXTgorilla
Twitterにて #PocketWP #ゴリ学習メモ なるスマホに最適化した暗号資産の学習情報をスライド形式にて発信しているゴリラ。 これまではTwitterのみの発信を行なっていましたが、蓄積される場所が欲しいという声にお答えし、Web化を行なってみました。
運営者情報② : CryptoGorillaz


  • Ethereum(ETH) / ERC20トークンでの投げ銭

森のお友達をご紹介 - PocketWPのオススメ

ゴリラが尊敬する森のお友達をご紹介するコーナー。 個人的に定期的に購読していただきたい!と思うメディアや事業者さまを勝手に紹介させていただいております。
StirLab | クリプト・ブロックチェーンを「深く」知る
クリプトアセット(仮想通貨・暗号通貨)に造詣が深い方々による寄稿型メディア「StirLab」。 クリプトが「好き」でその発展を純粋に「楽しむ」人たちが集まっており、ハイクオリティな記事が集まっています。 今話題のDeFiからSTOまでトピックは幅広く、知見を深めたい人にぜひとも定期的購読していただきたいサイトです。
StirLabさんのTwitterアカウントはこちら▶️ https://twitter.com/Stir_Lab
Stir | PoS系クリプトアセットのノード事業者
Tezos, Enigma, Cosmos, Ethereum, NEMといったPoS系クリプトアセットのマイニングやノード運用を代行する事業者。ブロックチェーン機構メディアで有名な「StirLab」の運営母体でもあります。
StirさんのTwitterアカウントはこちら▶️ https://twitter.com/stir_network