Development Update | DCG

Never miss a beat with Dash ➯ Subscribe

Note, the official update can be seen on YouTube, this is an unofficial text update based on the information that was provided in the video.

Let's quickly recap the sprint:

• Łukasz worked on improving the stability of TenderDash
• Igor, Ivan, Łukasz, and Konstantin and Odysseas integrated withdrawals into the platforms.
• Paul continued to work on strategies

During this sprint, the team tested TenderDash for stability, including heavy load mode. They identified some areas for improvement, which are currently being worked on.

Łukasz received feedback from the community on the TenderDash build process and made necessary changes, mainly related to documentation and dependencies. He also resolved minor issues with Docker images for different axes and linter. He cleaned up and improved the code.

The 0.14.0-dev.2 release included the THRESHOLD_RAW extension to make TenderDash compatible with the platform's withdrawal functionality. The main goal was to create a signature format that works with all layers (Core, Drive ABCI, and TenderDash) and allows secure and consensus-based withdrawal transactions to be signed.

This week, we focused on finalizing the platform's withdrawal function. While integrating with Core via the RPC method, we encountered determinism issues. To solve this problem, the team specified the block height in the Core chain up to which the status of a platform withdrawal transaction should be granted. Deterministic logic was achieved to allow Drive to correctly determine the completion of withdrawal transactions.

The week was dedicated to comprehensive optimization, code refactoring, and general code cleanup. Many tests were conducted covering a variety of scenarios. The tests included integration tests, tests for withdrawal strategies, and new functional strategies for state transitions. Additionally, end-to-end tests were conducted to ensure the reliability and robustness of the implemented functionality.

In this sprint update, Igor Markin demonstrated and explained the tests. Ivan Shumkov presented an infographic to help understand depositing and withdrawing funds on the Dash Platform.

Paul improved TUI functionality and created testing strategies for the Dash Platform. He made progress in registering multiple identities in a single blockchain and resolving issues related to credit transfers and state transitions. Additionally, he fixed a critical bug involving a mismatch between expected hash formats during state transition broadcasts, which resulted from merging the latest development branch with his working branch.

He improved the existing tests by testing the inclusion of multiple state transitions in a single block, expanding the testing capabilities. The testing approach was changed from a test network to a local network due to connectivity issues on the test network that could be caused by nodes interpreting stress tests as malicious activity. The local network is fast, allowing up to 500 state transitions in a single block, which is a significant improvement over the test network.

Paul is working to enhance contract operations by increasing the speed and number of contract registrations and updates. This requires optimizing the platform's ability to handle identity transactions and document management during the registration and update process. Currently, these operations are slow due to asset locking and waiting for confirmation from the core.

Tests were conducted to ensure the effectiveness and functionality of the DCG solution. The integrated version ran smoothly for a week without any issues. Therefore, after thorough testing, the solution was fully integrated.

State-based checking is computationally intensive. Transitions between states must be paid for, even if they do not pass state checking, to prevent system attacks. However, this mechanic also creates another attack vector.

For instance, if two users want the same username, only one can have it.

The two users create a state transition simultaneously. Although user B's state transition will be rejected, they will still pay a small processing fee.

Later, user C attempts to broadcast user B's failed state transition again, but it is once again checked and rejected. This allows the attacker to exploit someone else's balance.

To address this issue, the team developed a solution using a nonce based on an identity contract. Each contract between an identity and a pair of contracts has a unique nonce stored in the contract information space of the state of each identifier. The nonce value is incremented each time the identifier interacts with a contract, and state transitions update the nonce to nonce plus one. The nonce is also checked during document state transitions, such as add, update, or delete. Users can now make up to 20 state transitions for the same contract in a single block, which effectively solves the problem.

Although there were some difficulties encountered during the implementation of this solution, persistent efforts eventually led to its successful completion.

A major task was to address determinism issues associated with the RPC method used by Core. To ensure accurate reporting of asset unlock transactions, adjustments were made to define the level at which Core should provide information. The team optimized, refactored, and cleaned up the code. Extensive testing protocols were also implemented, including integration testing, strategy testing for withdrawal scenarios, and end-to-end testing. This thorough testing ensures that the code is robust and reliable in a variety of use cases.

Issues were resolved that addressed problems in the Drive ABCI execution logic. This logic maintains its own state, including current level and general information between blocks or block execution steps. It also stores basic information such as keys for signature verification. Initially, there were issues with serialization and disk storage, specifically the conflict of storing the log version with other state data. To address this issue, the team separated the log version into a separate key, allowing for smoother state analysis. They also identified inefficiencies in disk provisioning related to the caching of system data contracts. Because system contracts such as DPNS and withdrawals are heavily used during block execution and disk processing, the team implemented a separate cache for contract versions to optimize performance and avoid unnecessary computation. These enhancements improve the stability and efficiency of the Drive ABCI platform.

• The Core team has completed the Bitcoin Core backporting tasks scheduled for January, which has resulted in significant technical improvements and refactoring.
• Latteisnotcoffee is currently working towards obtaining a certificate that will allow to sign DCG releases.
• However, some features, such as Assume UTXO and Process Separation, were moved to version 21 as they were not yet ready.

The Core team has completed the Bitcoin Core backporting tasks scheduled for January. This work included the backport of Bitcoin Core version 20 and significant progress on versions 21 through 24. In particular, all backports for version 20 are now complete, paving the way for future improvements.

The default HD wallet implementations are almost finished and in the final testing phase. They will be integrated into the 20.1 rc1 release, which will start a release candidate cycle to test for any potential issues before the official release of version 20.1 in the near future.

The team is also working on becoming certified to sign releases, but progress is slower than expected due to various requirements. Planned for inclusion in version 20.1 are descriptor wallets, which are nearing completion and may be included as additional and experimental features.

However, some features, such as Assume UTXO and Process Separation, were moved to version 21 as they were not yet ready. Although the relevant code exists in 20.1, the final features are being developed for future releases. January's focus on the backport has resulted in significant technical improvements and refactoring. Although many of these changes are not readily apparent, they are valuable nonetheless.

The team has integrated several pull requests (PRs) over the past two weeks, primarily focusing on backports. Each PR on backports represents a significant amount of work, often involving 10 to 25 commits. These individual backports are small in size, but collectively they require a significant amount of work. There are likely around 100 to 200 of them in total.

• Work on CoinJoin has been advanced, the error handling issue has been resolved, and reliability and stability testing is almost complete. 
• DashDirect will be replaced by DashSpend as the new brand
• Rust libraries remains a top priority, the team is also focused on balancing feature development between Maya and Dash Spend.

During the last sprint, the Android team encountered an issue that is typical for Android 6. After evaluating the user base, which consisted of just over 100 users, the decision was made to discontinue support for Android 6, following the common practice of gradually phasing out support for older operating system versions.  

In addition, progress has been made in several areas: work on CoinJoin has been advanced, the error handling issue has been resolved, and reliability and stability testing is almost complete. 

Other developments include improvements in Maya, particularly the simplification of destination and receipt address input related to coinbase and uphold wallets. Specifically, DashDirect will be replaced by DashSpend as the new brand, and consideration of the new CTX API is currently ongoing.

Although integrating with new Rust libraries remains a top priority, the team is also focused on balancing feature development between Maya and Dash Spend.

The latest update also focused on libraries. The efforts are primarily aimed at creating an identification system, which is currently the team's top priority.

Notable achievements include fixing errors related to sorting coinbase and Dash Merchant in the Explore function.

In addition, work continues on the backend for CoinJoin, as well as minor fixes to the CrowdNode APY to align with new v20 calculations. 

Never miss a beat with Dash ➯ Subscribe

Note, the official update can be seen on YouTube, this is an unofficial text update based on the information that was provided in the video.