AITCA is a FREE platform for the creation and deployment of private blockchains, 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, AITCA 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 AITCA. Later we discuss several other features on the AITCA roadmap.
AITCA solves the related problems of mining, privacy and openness via integrated management of user permissions. The core aim is threefold:
- to ensure that the blockchain’s activity is only visible to chosen participants
- to introduce controls over which transactions are permitted
- to enable mining 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 size. In addition, as a closed system, the blockchain will only contain transactions which are
- of interest to those participants.
To understand permissions in AITCA, 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. AITCA 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:
- Each node presents its identity as a public address on the permitted list.
- Verifies that the other’s address is on its own version of the permitted list.
- Sends a challenge message to the other party.
- Sends back a signature of the challenge message, proving their ownership of the private key corresponding to the public address they presented.
- If either node is not satisfied with the results, it aborts the peer to peer connection.