Introducing the Darkchain

<aside> ✅ Darkchain is a private blockchain that addresses the aforementioned issues present in our theoretical research, either within or between organizations. It aims to overcome a key obstacle to the deployment of blockchain technology in the institutional financial sector, by providing the privacy and control required in an easy­to­use package. Like the Bitcoin Core software from which it is derived, Darkchain supports Windows, Linux and Mac servers and provides a simple API and command­line interface. In the next few sections we describe the first public release of Darkchain. Later we discuss several other features on the Darkchain roadmap.

</aside>

Darkchain solves the related problems of mining, privacy and openness via integrated management of user permissions. The core aim is threefold: (a) to ensure that the blockchain’s activity is only visible to chosen participants, (b) to introduce controls over which transactions are permitted, and to eliminate mining by transitioning to a new Proof of Entry (PoE) system to take place securely without proof of work and its associated costs. Once a blockchain is private, problems relating to scale are easily resolved, since the chain’s participants can control the maximum block In addition, as a closed system, the blockchain will only contain transactions which are of interest to those participants.

To understand permissions in Darkchain, we begin by noting that all cryptocurrencies manage identity and security using public key cryptography. Users randomly generate their own private keys and never reveal them to other participants. Each private key has a mathematically related public address which represents an identity for receiving funds. Once sent to a public address, those funds can only be spent using the corresponding private key to “sign” a new transaction. In this sense, access to a private key is equivalent to ownership of any funds which it protects.

Beyond controlling access to funds, this type of cryptography enables any message to be signed by a user to prove that they own the private key corresponding to a particular address. Darkchain uses this property to restrict blockchain access to a list of permitted users, by expanding the “handshaking” process that occurs when two blockchain nodes connect and only allows permissionless viewability of transactional nodes for NFT investments:

  1. Each node presents its identity as a public address on the permitted
  2. Each node verifies that the other’s address is on its own version of the permitted
  3. Each node sends a challenge message to the other
  4. Each node sends back a signature of the challenge message, proving their ownership of the private key corresponding to the public address they

If either node is not satisfied with the results, it aborts the peer-to-­peer connection.


The principle of connecting permissions to public addresses can be extended to many other operations on the network. For example, the right to send and/or receive transactions can be restricted to a given list of addresses, since transactions reveal the addresses of both senders and recipients. Since transactions can have multiple senders and recipients, a transaction is only allowed if all of its senders and recipients are permitted16. Indeed in some cases we may prefer the blockchain to be fully publicly viewable and only apply restrictions on the ability to transact. Finally, by adding a signature field to the coinbase transaction included by miners in blocks, Entry of Genesis Nodes in Darkchain can similarly be restricted17. As discussed in the next section, this is crucial to preventing minority rule in a private blockchain.

In Darkchain, all privileges are granted and revoked using network transactions containing special metadata. The deployment of the first “genesis” block automatically receives all privileges, including administrator rights to manage the privileges of other users. This administrator grants privileges to other users in transactions whose throughput contains those users’ addresses together with metadata denoting the privileges conferred. When changing the administration and transferability privileges of other users, an additional constraint is introduced, in which a minimum proportion of the existing administrators must vote to make a change. These votes are registered by each administrator in a separate transaction, with the change applied once sufficient consensus is reached. The first few blocks of a chain define a “setup phase”, in which a single administrator is able to bypass this voting process. Future versions of Darkchain could also introduce “super administrators” who can assign and revoke privileges on their own.

Since modifications to privileges are embedded in the metadata of transactions, they propagate quickly to all nodes in the network, creating consensus regarding the current state of play. However, because the network is decentralized, different nodes may receive permissions transactions at different times, either before or after other transactions. If the validity of a payment transaction depends on a privilege change that was broadcast shortly before, the difference could be critical, with some nodes accepting the payment and others rejecting it.

Any such differences will be resolved once the transactions are confirmed on the blockchain, fixing their final ordering. Every node follows the rule that transactions are ‘replayed’ in blockchain order, so each transaction in a block must be valid according to the state of user permissions immediately preceding it. If a transaction in a block is disallowed according to this rule, the entire block is rendered invalid. The miner of a valid block must also be on the permitted list after applying all privilege changes defined within that block’s transactions.


NOTES