Stage 8

Status: Testing in progress

1. UTXOs joining on deposit:

The efficiency of the product is improved by maintaining the user's balance in a single UTXO during the deposit. This allows users to engage their entire balance in a single transaction, eliminating the need for additional MASP transactions to consolidate smaller UTXOs.

The dApp maintains the user's balance in one UTXO for optimal clarity and efficiency, following the preference to have a single large UTXO instead of numerous smaller ones. This structure allows users to engage any part of their balance in just one transaction, mitigating the necessity for a supplementary MASP transaction to consolidate smaller UTXOs.

When handling a deposit transaction, the dApp merges an available zAsset UTXO of the largest amount with the deposited amount, rather than initiating a new UTXO. As a result, the new UTXO displays the total amount collected.

1. zAccounts blacklisting:

The update introduces a blacklist functionality, aimed at ensuring compliance with legal standards while maintaining the core privacy features. This update enables blocking users reported as illicit by reporting agencies.. ZMs can now oversee and manage such request of discovery of any bad actor in their zones and take measures more effectively

The blacklist feature is designed to integrate with existing compliance processes aligning with Panther’s broader compliance mechanisms.

1. Diamond Proxy updates:

The necessity of implementing the Diamond Proxy architecture in the product arose from the issue of contract size limitations on Ethereum. In the old design, PantherPool held multiple logics such as zAsset activation, PRP claiming, PRP conversion, the main transaction and zSwap, ForrestTree, and some helper functions. As a result, the PantherPool contract grew to around 30-32 kilobytes, which exceeded Ethereum’s limit for contract size, set at 24.6 kilobytes. The team initially addressed this by offloading some logic, but this solution was insufficient for future scalability, particularly with the planned introduction of zTrade functionality.

The Diamond Proxy resolves this by allowing multiple contract implementations to be accessed through a single proxy. This proxy can delegate calls to different contract implementations as needed while maintaining a shared storage across all implementations. The advantage of this architecture is that it bypasses the size limitations by distributing the logic across smaller, more manageable contract pieces, ensuring scalability as new features (such as zTrade), are added to the protocol. Each implementation can have its own storage while benefiting from the shared core storage managed by the proxy.

By implementing this architecture, the protocol can not only overcome the immediate size limitation but also future-proof its infrastructure for new functionalities and scaling, ensuring smooth deployment and upgrade processes in the future.

1. Taxi ring buffer logic updates:

The Taxi functionality got a significant upgrade with the introduction of a ring buffer mechanism, marking a substantial improvement in blockchain data management. This update revolves around the implementation of a smart contract supporting two level-8 Merkle trees, each containing 128 leaves. The core innovation lies in its cyclical approach: as one tree fills up with data, the system seamlessly transitions to the second tree while resetting the first to an empty state. This process continues in alternation, effectively creating a ring buffer that optimizes memory usage and streamlines data handling.

On the smart contract side, the implementation is elegantly simple yet powerful. Only the root of the current active tree is stored, significantly reducing memory requirements. The contract autonomously manages the transition between trees, including the reset process, ensuring efficient and continuous operation. Meanwhile, the data management component has been enhanced to track the current location of used UTXOs within the trees and utilizes only the latest state of the Taxi tree. This approach eliminates the need to maintain historical data, simplifying data queries and substantially reducing storage requirements.

The benefits of this ring buffer update are far-reaching. By cyclically reusing trees, the system avoids unbounded growth of data structures, leading to optimized memory usage and improved performance. The simplified data management process results in faster transaction processing and enhanced scalability, allowing the system to handle a larger volume of transactions without a proportional increase in resource requirements. Moreover, the focus on current state rather than historical data significantly reduces storage needs and simplifies verification processes.

1. Strengthening UTXO Management with Enhanced Privacy, Key Rotation, and Nullifier Security:

The code has been enhanced to address key issues related to UTXO management, with significant improvements focusing on privacy, security, and compliance. A set of critical updates was implemented to tackle vulnerabilities in the system, particularly regarding how UTXOs are verified and managed through compliance provider public keys and nullifiers.

The addition of a UTXO secret random to the zAsset commitment addresses a critical security vulnerability in the protocol. This update prevents potential cheating on the receiver's root spending key, which previously allowed for unintended anonymous transfers. By implementing this change, we ensure that every UTXO's spending public key is correctly derived from the receiver's root spending public key, maintaining compliance with the protocol's design. This enhancement effectively closes a loophole that could have allowed users to bypass essential verification steps, thereby strengthening the overall security and integrity of the transaction system.

Secondly, the handling of compliance provider public keys was updated to allow for key rotation and secure management. Previously, if a compliance provider's key was compromised, the protocol faced risks of unauthorized access or transaction manipulation. Now, the system ensures that these keys can be securely updated, while still maintaining the integrity of UTXO tracking. This prevents any security breaches linked to compromised keys and reinforces compliance protocols.

Finally, nullifiers - which are crucial for determining whether a UTXO has been spent - have also been enhanced. The system now ensures that nullifiers are securely generated and tied to the UTXO secret random and compliance provider keys. This update allows compliance providers to compute the nullifier and verify whether a UTXO has been used, without revealing sensitive user information. If needed, compliance providers can open a data escrow to investigate specific transactions. This addition guarantees that UTXOs are correctly tracked, preventing the reuse of spent tokens and ensuring secure transaction validation.

Together, these improvements significantly increase the security, privacy, and compliance capabilities of the protocol. This ensures the system is robust against potential manipulations and capable of securely handling UTXO transactions, even with future token standards or compliance requirements.

1. Streamlining Codebase with BigInt while Enhancing Efficiency and Reducing Dependency on External Libraries:

The code has been enhanced by standardizing the handling of large integer values, transitioning to the native BigInt type instead of relying on both BigInt and the BigNumber library from ethers.js. This improvement addresses the previous inconsistency, where the combination of these two types led to unnecessary conversions, complicating the codebase and increasing reliance on external libraries. These conversions not only affected the readability and maintainability of the code but also increased the risk of bugs due to the constant switching between formats.

By focusing on BigInt for all internal operations, the codebase has become significantly more streamlined and easier to maintain. The use of BigNumber is now restricted solely to cases where it is essential for smart contract interactions, reducing the overall complexity of the code. This approach also helps improve performance by eliminating the need for continuous conversions between BigInt and BigNumber.

Moreover, this update prepares the system for future improvements, as BigInt is expected to receive better support and optimizations within the evolving JavaScript ecosystem. As BigInt is a native JavaScript feature, this change ensures the codebase is more aligned with modern JavaScript standards and future-proofed for long-term sustainability.

1. Enhancing Token Management by Improving Security and Accuracy in Token Type Verification:

This test version has been improved by addressing a critical issue related to the proper identification and management of token types. Previously, the system did not accurately differentiate between various token standards (e.g., ERC-20, ERC-721, or ERC-1155), which allowed users to potentially misrepresent the type of token being used in transactions. This lack of verification created a security risk where users could manipulate the system, falsely claiming a token type and benefiting from this misrepresentation. Furthermore, the protocol lacked the infrastructure to store or verify this token information effectively, leading to potential vulnerabilities as more token standards are introduced.

To resolve this, a new solution was implemented that introduces the TokenTypeAndAddressDecoder library. This library enables the protocol to decode the public input of transactions and accurately return both the token type and token address. Additionally, the zTransaction and zSwap facets have been updated to ensure compatibility with the latest circuit updates, allowing them to accept token type and address in a single signal. The library then decodes this signal, ensuring that token types are correctly handled during transactions.

As a result, the product now offers improved security by accurately verifying token types and addresses, minimizing the risk of system manipulation. This enhancement not only addresses the immediate security concerns but also prepares the system for future expansions, allowing it to handle a wider variety of token standards with increased reliability and efficiency.