SC: Add Modularity to ChainLib Contract #52
Description
##Description
The current ChainLib StarkNet contract is a monolithic implementation that encompasses multiple functionalities, including account management, user management, content management, subscription and payment handling, access control, delegation, and purchase management. To improve maintainability, readability, and scalability, we should refactor the contract to introduce modularity by breaking it into separate components or modules.
Proposed Solution
Refactor the ChainLib contract into distinct modules/components to separate concerns and improve code organization. The proposed breakdown includes:
Account Management Module:
Handles TokenBoundAccount creation and retrieval (create_token_account, get_token_bound_account, get_token_bound_account_by_owner).
Manages account-related storage (accounts, accountsaddr, current_account_id).
User Management Module:
Manages user registration and verification (register_user, verify_user, retrieve_user_profile, is_verified).
Manages user-related storage (users, user_by_address, user_id).
Permission Management Module:
Handles permission-related functions (set_operator_permissions, revoke_operator, modify_account_permissions, get_permissions, has_permission).
Manages permission-related storage (operator_permissions).
Content Management Module:
Manages content registration and retrieval (register_content, get_content).
Manages content-related storage (content, creators_content, next_content_id, content_tags).
Subscription and Payment Module:
Handles subscription creation and payment processing (process_initial_payment, process_recurring_payment, verify_payment, process_refund, create_subscription, get_user_subscription).
Manages subscription and payment-related storage (subscriptions, subscription_id, user_subscription_count, user_subscription_by_index, payments, payment_id, subscription_payment_count, subscription_payment_by_index).
Access Control Module:
Manages access rules, verification requirements, and premium access (set_content_access_rules, add_content_access_rule, get_content_access_rules, set_verification_requirements, get_verification_requirements, check_verification_requirements, grant_content_permissions, has_content_permission, grant_premium_access, revoke_access, get_premium_access_status, verify_access, _determine_access, initialize_access_control, set_cache_ttl, clear_access_cache).
Manages access-related storage (content_access, premium_content_access, access_cache, access_blacklist, cache_ttl, content_access_rules_count, content_access_rules, content_verification_requirements_count, content_verification_requirements, user_content_permissions, user_verifications, user_identity_verifications, user_payment_verifications, user_reputation_verifications, user_ownership_verifications, user_custom_verifications).
Delegation Module:
Manages delegation creation, usage, and revocation (create_delegation, revoke_delegation, is_delegated, use_delegation, get_delegation_info).
Manages delegation-related storage (delegations, delegation_nonces, delegation_history).
Purchase Management Module:
Handles content purchases and price management (set_content_price, purchase_content, get_purchase_details, get_user_purchases, verify_purchase, update_purchase_status).
Manages purchase-related storage (content_prices, next_purchase_id, purchases, user_purchase_count, user_purchase_ids, content_purchase_count, content_purchase_ids).
Implementation Details
Separate Modules: Create separate Cairo files for each module (e.g., account_management.cairo, user_management.cairo, etc.).
Interfaces: Define clear interfaces (traits) for each module to ensure loose coupling and interoperability.
Storage Separation: Split the Storage struct into module-specific storage structs to reduce storage conflicts and improve clarity.
Event Separation: Organize events by module, ensuring each module emits its own events.
Dependencies: Ensure modules can interact via well-defined interfaces (e.g., AccessControl may depend on UserManagement for user verification).
Reusability: Design modules to be reusable in other contracts if needed.
Testing: Update or create new tests to cover each module independently and their interactions.
Acceptance Criteria
Each module is implemented in a separate Cairo file.
Clear interfaces (traits) are defined for inter-module communication.
Storage is split into module-specific structs.
All existing functionality is preserved after refactoring.
Unit tests are updated to cover individual modules and their interactions.
Documentation is updated to reflect the modular structure.
Gas usage is not significantly increased (or is optimized where possible).