The team at HandCash has actively been testing and providing feedback for the introduction of ARC, says Rafa Jimenez (Chief Technical Officer and Co-Founder of HandCash). ARC is a multi-layer transaction processor that keeps track of the life cycle of a transaction as the BSV blockchain processes it.
‘In the BSV blockchain network there are many different layers. In particular, there is a Mining layer and on top there is a Service layer. You want the services to send transactions to miners so that they can be validated and eventually included in the block. So ARC is another tool to communicate between these two layers,’ explained Jimenez.
He noted that the process for validating transactions is not binary. ‘There are some steps in between – especially when it comes to instant confirmation of a transaction. What is nice about ARC is that it gives you much more information around the transition from not being included to being included, so you can evaluate the transaction risk assessment and make a decision on top of that. This is very important to us when it comes to achieving stability.’
The importance of interoperability
Jimenez said that the BSV blockchain is ultimately built on top of stability and interoperability but noted that it can be daunting for developers and it can take them a lot of time to integrate the technology into existing processes.
‘When you are building a new product you want to make sure you are building the right product as soon as possible – which is where Handcash comes in very handy for them,’ he said. ‘We are now in a position where we can say that we are very happy with the way ARC is coming along and it is very stable.’
An introduction to ARC’s microservices
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.
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.
