New Highload Wallet

[pyAndr3w]

Summary

Highload wallet implementation in the TON blockchain is currently bulky and has security concerns. This issue proposes a leaner and more secure alternative to the current highload wallet design.

Context

Highload wallet is smart contract in the TON blockchain designed to manage a large volume of transactions effectively while ensuring the security of assets. However, the existing implementation has been found to be bulky, leading to higher operational costs and security issues. One of the key problems in the current implementation is the overflow of the hashmap of requests. If an overflow occurs, the smart contract can become completely inoperative, leading to loss of functionality and potentially compromised security. Given these concerns, a new design is needed to ensure the wallet remains efficient and secure even under heavy transaction loads.

Goals

1. Create a more secure and cost-effective implementation of the highload wallet.
2. Simplify the existing design to reduce complexity and improve usability.
3. Fix current security issues, including the hashmap overflow problem.

Deliverables

1. Smart Contract: Develop a new smart contract for the highload wallet, optimizing for performance, security, and resistance to hashmap overflow.
2. TL-B Schema: Create and document a TL-B schema for the request/response interactions with the smart contract.
3. Contract Tests: Write comprehensive tests to validate the smart contract's functionality, robustness against common vulnerabilities, and protection against hashmap overflow.
4. Usage Example in TypeScript: Provide a working example of how to interact with the smart contract using TypeScript, serving as a reference for developers looking to integrate or interact with the redesigned highload wallet.

Definition of Done

• Smart Contract on fift-asm
• Smart Contract on FunC (extra-version)
• Full specification
• Detailed documentation with edge cases
• Usage example in typescript (ton-core) and c# (tonsdk.net)
• Blueprint tests and wrappers for the contract
• The code review by @akifoq

Reward

• Standard TON Footstep NFT
• 1500 USD in TON equivalent
• 750 USD in TON equivalent (The code review by @akifoq)

Oriental Release Date

One month after approving

[pyAndr3w]

@delovoyhomie, what do you think about it?

[Naltox]

@pyAndr3w happy to discuss it in DM at telegram :)

[Naltox]

@pyAndr3w lets add "blueprint tests and wrappers for the contract" to the deliverables.
Also i think 1200 USD would make much more sense in terms of pricing.

Other than that we are good to go!

[pyAndr3w]

@Naltox regarding the reward, I believe we should take into consideration that the development is planned for Fift-asm, not FunC, which will provide more opportunities for optimizations but will require slightly more effort.

[pyAndr3w]

@delovoyhomie, I'm ready to start developing in the current view

[pyAndr3w]

@delovoyhomie,

The smart contract is almost ready. I just need to add the "processed?" get-method (is this get-method necessary at all?).

I've written some tests, but I still request a review.

Since the contract is written in fift-asm, it requires someone with sufficient expertise for review. I suggest @Skydev0h or @akifoq, as they have significant experience specifically in fift-asm.

Repository link: https://github.com/continuation-team/highload-wallet-v3/tree/draft

[pyAndr3w]

Features of the new highload wallet:

• Performs the "cleanup hashmap in 1 action" instead of iterating through the hashmap in a loop, as implement in v2. This allows clearing the hashmap at the beginning of execute, enabling the wallet to be used even if the hashmap is fully occupied.

• Requests are stored as 1 bit in the hashmap, as opposed to 1 entry in v2. This means that instead of 32k entries, it can store 16 million, allowing for many more requests to be sent without overloading the hashmap.

• "Hardcoded" valid_until set to 128 seconds. This fixes the issue in v2 where entries with a large valid_until took a long time to be removed from the hashmap, potentially leading to hashmap overload and making it impossible to continue using the wallet.

• Uses "preprocessed c5" instead of a hashmap for messages. This significantly reduces gas consumption when sending messages.

[delovoyhomie]

Now a code review from @akifoq and @EmelyanenkoK is being conducted.
@akifoq, could you please confirm your readiness here for a compensation of $750?

[akifoq]

I confirm it.