ARK Development Report - August 25, 2023

Welcome to our latest Weekly Development Report, where we spotlight the valiant efforts of our development team. In the past week, we launched a fresh edition of ARK Scan featuring an upgraded ‘Delegates’ page. Notably, we achieved significant advancements in enhancing the efficiency of Dashbrd API requests and database queries. Our ongoing efforts also extended to refining consensus optimization for Mainsail.

#Development Summary

Below is a breakdown of total commits and authors by project for development activity over the last week from August 18th through August 25th, 2023.

Overall, the team has demonstrated consistent productivity and engagement over this period, with a total of 182 commits across all projects.

The number of commits and data for each project will fluctuate on a weekly basis depending on internal sprints, objectives and difficulty.

#ARK Scan Weekly Progress

This week, a fresh version of ARK Scan has been made available. In this release, modifications have been made to the Delegates page, making it easier for everyday users to access essential delegate information. Furthermore, the Delegate Monitor has been relocated to its own separate page, as its usage is primarily aimed at delegates themselves. You can find additional information about these changes in our release blog post.

Looking ahead, the next phase of development will focus on revamping the dedicated ‘Transactions’ and ‘Blocks’ pages.

#Dashbrd Weekly Progress

This week, our focus remained on internal testing, and our development team concentrated on optimizing the retrieval of collections and NFT data, alongside enhancing the speed of certain database queries. Here are the specifics:

#Dashbrd General Items

• We have now distinguished between rate limits and connection exceptions, allowing us to release the job back into the queue after a certain interval.
• Scheduled jobs have been spaced out more effectively to ensure that critical data remains consistently up to date.
• The Cookie script has been transitioned to a regular script file, separate from the react codebase. This change prevents application disruptions caused by potential blocking of the script.
• The wallet connect button is now disabled during maintenance mode.
• Failures for jobs using Mnemonic, Alchemy, Footprint, and Moralis APIs are handled more effectively.
• React query is now used for portfolio breakdowns.
• Integration of the Tailwind prettier plugin.

#Dashbrd Wallet Items

• Token balances now update faster after a transaction has been confirmed.
• Corrected inaccuracies in calculating price change percentages, ensuring accurate representation.
• Token details updating is now prioritized based on a predefined algorithm.
• The send transfer tab is disabled when the wallet has a zero balance.
• Token prices are fetched more efficiently in the background jobs, with token details being updated every 15 minutes.
• Added contract checks to manage token-related spam.
• Improved frequency of balance updates for connected wallets.
• More efficient handling of excessive platforms in Coingecko tokens.
• Utilization of the wallet and network model in the FetchNativeBalances job, leading to a reduction in the number of SQL queries required.
• Reworked usage of FetchTokens with UpdateTokenDetails to avoid redundant calls.

#Dashbrd Collections & Gallery Items

• NFTs for collections without a total supply are no longer indexed. This commonly applies to ENS domains.
• Adjustments have been made to the command for fetching activities of owned NFTs to prevent job accumulation and queue congestion.
• The wallet model is used instead of a data object when resolving ENS domains.
• Enhanced handling of collection start tokens ensures storage of the highest token number each time all NFTs for a collection are indexed.
• Alchemy spam contracts are now stored in the database.

In the coming week, our focus will continue to be on optimizing the Dashbrd app’s database functions to ensure a smoother user experience and more up-to-date data. We will also address any remaining bugs identified by our testing team. As the open Beta launch approaches, stay prepared!

#Mainsail Weekly Progress

Mainsail’s ongoing efforts encompass refining consensus-related aspects and optimizing the codebase. Here are the key updates:

• LMDB stores have been divided into multiple files. ledger.mdb contains committed data like blocks and transactions, while consensus.mdb houses uncommitted data for restoring block rounds. This uncommitted data includes prevotes, precommits, proposals, height, and round numbers.
• To enhance readability, consensus logs now use validator usernames instead of public keys.
• A ValidatorWallet factory has been introduced in the state package. This helps in separating code and preventing direct creations in related packages. ValidatorWallet is responsible for encapsulating a wallet by the validator and offers additional methods such as getUsername, getConsensusPublicKey, and getWalletPublicKey.
• Refactoring has been done on RoundState and validator-set related code. Validator indexes are now used instead of public keys to access ValidatorWallet instances.
• Enhancements have been made to the proposal serialization with the addition of ValidRound. The serializer now supports various optional fields like uint8, uint32, bigInt, address, and more.
• Consensus code improvements include the incorporation of validRound checks.
• The Aggregator class, responsible for creating and validating aggregated signatures, has been simplified. It now provides generic aggregate and verify methods instead of specialized ones for lock proofs and committed blocks.
• Verification processes for signatures and lock proofs have been moved under the respective processor classes.
• The verification of the block generator’s public key now takes place in the ProposalProcessor rather than within the block processor. This change acknowledges that the correct block generator can only be checked for the first proposal of a block. On re-proposals of a locked block, the accurate block generator cannot be determined, but trust is placed in it due to the presence of proof with +2/3 prevotes, and validators that prevoted the initial proposal must have already verified it.

Looking forward, the upcoming week’s objectives include implementing block processor locking and committing blocks in an atomic manner. Processing and verifying Blocks, Prevotes, Precommits, and Proposals will wait while crucial state changes occur during the commit. Initial API implementation will also commence, along with an evaluation of the test network for potential issues and subsequent fixes.

#Feedback & Feature Requests

If you are using our open-source products and would like to provide feedback or request a feature, please feel free to contact us via the contact pages for the specific product you are using or open an issue on GitHub.

Quick access links to GitHub issues pages:

• Mainsail
• ARK Scan
• ARK Vault
• Dashbrd (coming soon)

#What’s Next

Looking ahead to the upcoming week, our primary focus remains aligned with completing the last rounds of database and API optimizations as part of our preparations for Dashbrd’s open Beta launch. Additionally, our ongoing efforts include the enhancement of ARK Scan, specifically concentrating on the redesigned Transactions and Blocks pages. Moreover, progress will be made on initiating the API implementation for Mainsail.

Follow us on X and keep checking the blog to stay up-to-date on all of our new releases. We post a weekly development report so you can easily see what we’ve been up to and follow along our journey towards making your decentralized future a reality.