AlgoExplorer: A tool for retrieving human-readable data from the new Blockchain Algorand.
As you probably know (or you should if you are in the crypto environment), there is a new blockchain right around the corner: Algorand. We are glad to have the opportunity to contribute to the Algorand ecosystem.
This project, led by Silvio Micali, is not meant to be a clone of previous blockchains, most of which lack at least one of the features in the ‘blockchain trilemma’.
The blockchain Trilemma
Proof of Work and Proof of Stake
Algorand solves all three – decentralization, scalability, and security – at the same time. Proof of work has been a successful approach to solving the security issues raised when the participating parties are strangers to each other.
There are, however, at least two problems with Proof of Work. Firstly, it is resource intensive; and secondly, large mining pools or any other group with a majority could make fake transactions.
Would you trust a network like that? Well, that’s just what Bitcoin and Ethereum, among others, do. Other blockchains use different proof systems, which have other weak points too. One of them, is keeping the anonymity of the next block creator as unknown. As you are probably wondering, here is where Algorand comes.
Proof of stake is a proof system in which miners don’t compete each other to be the first entity that mines a block; instead, the probability to be the one that builds the next block, is weighted by the number of assets that you have involved into the network. The idea behind is: will you risk a lot of assets to fake transactions and kill the network (and with it your assets)? If you are a multimillionaire that doesn’t bother to lose a pile of money, maybe you could answer yes, but for the rest of the population, the answer will be no.
‘But there are other types of blockchain that are implementing PoS, why this one is so different?’ – you may say. Well, not only has PoS and allows a higher TPS, but also uses a verifiable random function (VRF) to determinate who will create the next block – or who will be a jury – without knowing beforehand who is it and also, without pre-block messages! Even in each block, there are several steps to reach consensus, and in those steps, the committee is always replaced with new members using the VRF. This increases security since no one knows who the next block proposer will be, and you cannot bribe or attack any specific node.
I know, you are amazed, you want to buy all their coins right now and forget about the existence of other blockchains, but here is the downside: This project is still under development and although it’s getting ready pretty fast, only a testnet is available to the public. But here is where we come: for the rest of the developers that use that testnet, we have a surprise tool for you: AlgoExplorer.io.
There, you will find a block explorer that it will quickly retrieve you information regarding the most common queries, such as the latest transactions made in the network, the balance of an account with their transaction history log, the data from a certain block and we let you find the rest of the features.
One of the toughest challenges we had, was the response times once the network reaches a high number of transactions. To combat this issue, several architectures, implementations of the API and database types were studied and tested in a private network with high transactions count (reaching up to 700 TPS in a low specs VM).
Technologies involved in the project
The technologies utilized in the development were Python and Node.js for the modules, and mySQL & MongoDB for the database. During tests, MongoDB was the database that showed a better integration with the problem when the size of the blockchain increased over time. Nevertheless, improvements never stop!
Our current configuration is as shown in the following picture
As you may see, all the backend is modularized to self-contain each task or process. Also, the indexed database is used as a buffer between the indexing process and the output data to humans. This allows a future upgrade of one of the modules without disrupting the rest of the backend. One example of this occurred in the API Handler module, which was originally constructed using Python but then it was ported to Node.js to improve the response time to the users.
The developing process of the tool is always in movement. We try to keep up with the needs of the network while it evolves, and here is where all of you can help: nothing is better for knowing the needs than its users. Feedback on the needs, new features, and issues are always welcomed!
If you think that you can aport your 2 cents, feel free to write us to firstname.lastname@example.org.
We are always looking forward to giving a better service to the community! 🙂