The team at TAAL has continued testing with ARC as it gears up for a full release later this year, says Michael Böckli (Tech Lead at TAAL). The ARC open-source reference implementation has been commissioned by BSV Blockchain and developed by TAAL to leverage their deep knowledge and expertise in transaction processing.
In addition to developing the open-source version of ARC following open-source guidelines and requirements handled by the BSV Blockchain, TAAL also runs its commercial version and proposes it as a commercial and enterprise-grade service to businesses.
Speaking on the sidelines of the London Blockchain Conference 2024, Boeckli noted that the ARC development process has been ongoing for well over a year. ‘So ARC was meant to be a replacement for mAPI, but it has become a lot more than that,’ he said.
‘ARC works a bit like a node itself – it is not simply a program which does RPC calls to the node. It is all ready for the future of Teranode shortly. Before we reach that point, however, ARC will need further adaptations and more extensive development, he said.
Böckli noted that ARC is going to be one possible node in the Overlay network which can be used and run by everybody. However, he predicts that there will also be modified ARC versions for specific use cases and industries. ‘Anybody can create a completely new implementation – but ARC is essentially the reference for such a component.’
This leads to a discussion between open-source and commercial applications, he said. Böckli noted that while TAAL is actively working on the overall development of ARC, it is also working on improving monitoring and could ultimately develop some optimisations which are not open-source.
This does not mean that open-source development will stop, and he noted that he and his team are still actively working to help deploy ARC in time for the Teranode upgrade later this year.
A brief overview of ARC
ARC is a multi-layer transaction processor that keeps track of the life cycle of a transaction as the BSV blockchain processes it.
Unlike other transaction processors, ARC broadcasts all transactions on the P2P network and does not rely on the RPC interface of a single node. This makes it possible for ARC to connect and broadcast to any number of nodes, as many as are desired.
In the future, ARC will be also able to send transactions using ipv6 multicast, which will make it possible to connect to a large number of nodes without incurring large bandwidth costs.
The ARC design decouples the core functions of a transaction processor and encapsulates them as microservices with the ability to scale horizontally adaptively. Interaction between microservices is decoupled using asynchronous messaging where possible.
ARC’s microservices include the API server, validator (with the ability to scale for increased workload), metamorph for managing changing transaction statuses, and a peer manager to handle connections. Additionally, ARC stores a new format of blocks containing transaction IDs rather than full transaction data. This architecture aims to enhance transaction reliability and efficiency in the BSV blockchain network. ARC consists of four microservices: the API, Metamorph, BlockTX and Callbacker.
The ARC API: The API serves as the interface for interacting with the ARC system, featuring several key endpoints. These include a policy endpoint for setting requirements like the mining fee in satoshis per byte and a transaction submission endpoint for processing transactions in parallel or serially. Transactions are submitted in an “extended format”, which includes additional information for script validation and fee checks, overcoming the limitations of using raw transaction data. This format requires a UTXO lookup service, currently under development, to verify transactions before broadcasting, enhancing reliability.
Metamorph: Metamorph’s role is to place pre-validated transactions on the blockchain via the peer-to-peer network. It can connect to multiple instances to handle high transaction volumes using round-robin load balancing. Metamorph processes transactions from the API, monitors their status, and forwards updates as needed.
BlockTx: BlockTx is a microservice that listens for peer-to-peer messages, especially block announcements. Upon detecting a block announcement, it retrieves and processes the necessary data, focusing on verifying that transaction IDs are part of the Merkle root in the block header. BlockTx hashes transactions to create a list of transaction IDs and calculates the Merkle path for relevant IDs, updating their status to “mined” and storing the paths according to BRC 71 standards.
Callbacker: The Callbacker service enables users to monitor the status of their transactions. Through the API’s “get tx” endpoint, users can check transaction statuses and specify which updates they wish to receive. Users can provide a URL and token to receive notifications when transaction statuses change, including mining status and Merkle path data.
