Adding Support For Voting New Approved Code Hash On Devnet A Comprehensive Guide

by gitftunila 81 views
Iklan Headers

This document outlines the proposal to add a new feature to the devnet CLI that will allow developers to vote for new approved code hashes on the devnet. This functionality is crucial for enabling end-to-end (E2E) testing of Trusted Execution Environment (TEE) enabled networks, specifically in the context of the NEAR Meta Pool Contract (MPC). The ability to vote for and add new MPC image hashes to the contract is essential for developers to thoroughly test and validate the functionality of TEE-integrated applications within the NEAR ecosystem. This enhancement will streamline the testing process and ensure the reliability and security of TEE-based solutions.

Background

In the context of E2E testing for TEE-enabled networks, the contract needs to maintain a list of approved Docker image hashes. These hashes serve as a security measure, ensuring that only trusted and verified code is executed within the TEE. Currently, adding a new MPC image hash requires calling the vote_cancel_resharing method on the contract. This process involves specific steps and configurations, which can be cumbersome for developers during the testing phase. To simplify this, we propose adding a CLI option to the devnet tool that will streamline the process of adding new MPC image hashes.

The existing contract method, vote_cancel_resharing, located in the NEAR MPC repository, plays a vital role in managing the approved code hashes. However, directly interacting with this method for testing purposes can be time-consuming and complex. By introducing a dedicated CLI option, we aim to abstract away the underlying complexities and provide developers with a more intuitive and efficient way to manage approved code hashes. This will not only accelerate the testing cycle but also reduce the potential for errors during manual configuration.

The relevant code snippet from the NEAR MPC repository highlights the importance of this method in the contract's functionality:

// https://github.com/near/mpc/blob/1597faf1e2e1ae744b041cdcf6d2974346381219/libs/chain-signatures/contract/src/lib.rs#L854-L855
// The `vote_cancel_resharing` method is used to add an MPC image hash.

This code snippet underscores the need for a more accessible way to interact with this functionality, especially in a testing environment. The proposed CLI option will bridge this gap, making it easier for developers to integrate and test TEE-enabled applications.

User Story

As a developer, I want to be able to easily add new MPC image hashes to the contract on the devnet so that I can perform comprehensive E2E testing of TEE-enabled networks. This functionality is critical for ensuring the reliability and security of our applications that rely on TEE for sensitive computations. The current process of manually interacting with the contract is time-consuming and prone to errors, which hinders our ability to iterate quickly and thoroughly test our code. By providing a streamlined CLI option, we can significantly improve the efficiency of our testing workflow and ensure that our TEE-enabled applications meet the highest standards of security and performance.

The ability to perform E2E testing in a TEE-enabled network is paramount for applications that handle sensitive data or require secure computations. Without proper testing, there is a risk of vulnerabilities and unexpected behavior that could compromise the integrity of the system. Therefore, providing developers with the tools they need to effectively test their applications is essential for the success of the NEAR ecosystem. This user story highlights the importance of simplifying the process of adding new MPC image hashes to the contract, thereby empowering developers to build and deploy secure TEE-enabled applications with confidence.

Acceptance Criteria

The primary acceptance criterion for this feature is the successful implementation of a new CLI option within the devnet tool that allows developers to add a new MPC image hash to the contract. This CLI option should be intuitive to use and provide clear feedback to the user regarding the outcome of the operation. The addition of a new MPC image hash should be reflected in the contract's state, and the developer should be able to verify this change through appropriate means. The CLI option should also handle error conditions gracefully, providing informative error messages to the user in case of failures.

Specifically, the acceptance criteria include:

  • A new CLI option, such as --add-mpc-hash, is added to the devnet command.
  • The CLI option accepts the new MPC image hash as an input parameter.
  • The CLI option interacts with the contract to add the provided MPC image hash to the list of approved hashes.
  • The CLI option provides feedback to the user upon successful addition of the hash.
  • The CLI option handles potential errors, such as invalid hash formats or contract interaction failures, and provides informative error messages.
  • The functionality is tested thoroughly to ensure its reliability and correctness.

Meeting these acceptance criteria will ensure that the new CLI option effectively addresses the user's need for a streamlined way to add new MPC image hashes to the contract, thereby facilitating E2E testing of TEE-enabled networks.

Detailed Design

The proposed solution involves modifying the devnet CLI to include a new option specifically designed for adding MPC image hashes. This option will encapsulate the necessary steps to interact with the contract and update the list of approved hashes. The design considerations include user experience, error handling, and security.

CLI Option Implementation

A new subcommand, possibly named devnet mpc-hash add, will be introduced. This subcommand will accept the MPC image hash as an argument. The CLI will then construct a transaction to call the vote_cancel_resharing method on the contract, passing the provided hash as a parameter. The CLI will handle the transaction signing and submission process, providing feedback to the user on the transaction status.

Contract Interaction

The CLI will need to interact with the contract's vote_cancel_resharing method. This interaction will involve constructing a function call transaction, signing it with a designated account, and submitting it to the network. The CLI will need to handle potential errors during this process, such as transaction failures or insufficient gas fees.

Error Handling

The CLI will implement robust error handling to provide informative messages to the user in case of failures. This includes validating the MPC image hash format, handling transaction errors, and providing feedback on insufficient gas fees or other issues. Error messages should be clear and actionable, guiding the user on how to resolve the problem.

Security Considerations

The CLI will need to securely manage the keys used to sign transactions. This may involve using a secure key storage mechanism or prompting the user for their credentials. The CLI should also validate the MPC image hash format to prevent potential vulnerabilities.

User Experience

The CLI option should be easy to use and provide clear feedback to the user. The command syntax should be intuitive, and the output should be informative. The CLI should also provide help messages and usage examples to guide the user.

Implementation Plan

The implementation of this feature will involve several key steps, including setting up the development environment, implementing the CLI option, writing unit and integration tests, and documenting the new functionality. A phased approach will be adopted to ensure that each component is thoroughly tested and validated before moving on to the next phase.

Phase 1: Setup and Core Logic Implementation

This phase will focus on setting up the development environment and implementing the core logic for the CLI option. This includes:

  1. Setting up the development environment with the necessary dependencies and tools.
  2. Implementing the CLI option, including parsing command-line arguments and validating input.
  3. Implementing the logic to interact with the contract's vote_cancel_resharing method.
  4. Implementing basic error handling and feedback mechanisms.

Phase 2: Testing and Refinement

This phase will focus on writing unit and integration tests to ensure the functionality is working correctly. This includes:

  1. Writing unit tests for the core logic components.
  2. Writing integration tests to verify the interaction with the contract.
  3. Refining the implementation based on test results and feedback.
  4. Implementing more robust error handling and feedback mechanisms.

Phase 3: Documentation and Finalization

This phase will focus on documenting the new functionality and preparing it for release. This includes:

  1. Writing documentation for the CLI option, including usage examples and explanations.
  2. Updating the devnet CLI's help messages to include the new option.
  3. Performing final testing and validation.
  4. Preparing the changes for integration into the main branch.

Resources & Additional Notes

Currently, there are no additional resources or notes beyond what has been provided in the background and user story sections. However, as the implementation progresses, additional resources may be identified and added to this section.

Conclusion

The addition of a CLI option to the devnet tool for voting on new approved code hashes is a crucial step in enabling E2E testing of TEE-enabled networks within the NEAR ecosystem. This feature will streamline the testing process, reduce the potential for errors, and ultimately contribute to the reliability and security of TEE-based applications. By providing developers with a more intuitive and efficient way to manage approved code hashes, we empower them to build and deploy secure and robust applications on the NEAR platform.