ARC is the answer for developers who are creating a lot of transactions and need to push a lot of transactions on-chain quickly, says David Case (1SatOrdinals Developer). Speaking on the sidelines of the London Blockchain Conference 2024, Case said that existing tools are not very effective at this.
‘So I ended up doing a lot of work in my projects having to build all sorts of second layer stuff to ensure that when I broadcasted a transaction it would get mined. And then when the ARC project came along, it seemed like the kind of tool that would solve all the extra work I was having to do, so I wouldn’t have to worry about that anymore,’ he said.
Testing and use cases
Case said that he became involved in ARC after he began testing on the project, including tests with Rekord IoT to explore the number of transactions that the BSV blockchain could reliably handle.
‘And so we engaged the BSV Blockchain to do a performance test of ARC and help them push ARC forward. And so we did four or five different short-term bursts of tests,’ he said. Case added that these tests subsequently led to a lot of bug tests and a true evaluation of the ARC system.
‘It wasn’t that smooth of a process. It broke. But it was a very valuable process to then fix those things, collect data on it and figure out what’s breaking. And it became a much better product through that process,’ he said.
Case note that TAAL and GorillaPool are still using ARC. However, he noted that the ultimate problem is how users get transactions broadcasted to the miners. ‘And that’s the problem that ARC solves – it provides an interface where end users can broadcast a transaction and have a mechanism to measure the outcome. Whether it got mined, rejected etc.
‘It’s a tool that the ecosystem needs to close the gap between end users and miners, so it makes a ton of sense for miners to run it as a mechanism for simply acquiring transactions.’
A brief overview of ARC
ARC is designed to connect to every mining node on the network and includes peering logic, retry logic for transaction tracking, transaction validation, and an API for clients. It also calculates Merkle paths for broadcasted transactions.
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.
