Skip to content Skip to sidebar Skip to footer

12142 | Text Proposal – Removal of Forked Modules from Terra Classic

7 min read 1,282 words 240 views

Executive Summary

OrbitLabs proposes to remove the forked mainline modules from the Terra Classic blockchain to improve maintainability, reduce technical debt, and align with the broader Cosmos ecosystem.

For a comprehensive introduction of our teams and qualifications, please take a look at: https://hackmd.io/@orbitlabs/SJiDiG22A

Current Situation

The Terra Classic codebase currently uses several forked versions of Cosmos modules to accommodate its unique features. These forks have caused the codebase to increasingly diverge from the upstream modules, increasing maintenance costs as long as it persits.

With the current versions of Luna Classic and the upstream modules, we now have the opportunity to:

  • Remove the forked modules maintained by the Terra Classic team
  • Integrate the standard upstream modules
  • Port Terra Classic specific changes to the Terrad module itself

This approach would allow Terra Classic to inherit up-to-date securities and features from the Cosmos development team, massively reducing maintenance costs and time.

Terra Classic Customizations/Forks

#### CosmosSDK:

  • Custom logic for OracleTx: Support for Oracle transaction priority handling.
  • Custom staking logic: Limit validator voting power to 20%.

#### CometBFT (formerly Tendermint):

  • Oracle Transactions: Added functionality to process Terra Classic specific Oracle transactions.

#### Wasmd

  • Key Deprecation: The current keys used in Terra Classic’s Wasmd fork are deprecated. This affects how contract-related data is stored and accessed within the blockchain state.

Consequences of No Action

If we do not address this issue:

Increased Maintenance Costs

As Terra Classic continues to maintain forked versions of the core Cosmos modules, the burden of keeping these forks in sync with upstream developments will increase. This will require significant ongoing developer resources to manage updates, bug fixes, and compatibility, resulting in increased operational costs.

Missed Upstream Improvements

By diverging from the mainline Cosmos SDK and related modules, Terra Classic risks falling behind in adopting key enhancements and new features developed by the broader Cosmos community. This can limit Terra Classic’s competitiveness and make it more difficult to integrate future technologies, upgrades, performance improvements and other innovations.

Increased Security Risks

Delayed adoption of upstream security patches and vulnerability fixes will expose the Terra Classic chain to potential exploits. The longer Terra Classic remains on forked, outdated modules, the greater the risk of being affected by known vulnerabilities that have already been fixed in the Cosmos ecosystem.

Restrained Developer Ecosystem

A codebase that is increasingly out of sync with the mainline Cosmos ecosystem may discourage L1 developers from contributing to Terra Classic. Developers would face additional complexity in learning the codebase, potentially limiting innovation and developer engagement.

Proposed Solution

We propose to remove the forked mainline modules and replace them with the standard Cosmos modules. This process will be divided into two phases

Phase 1

  • Unfork CometBFT from v0.37.4-terra1 to the mainline v0.37.4 version
    • This will involve updating the consensus engine to align with the 0.37.4 version of CometBFT
    • Extensive testing will be required to ensure network stability
  • Update CosmosSDK from v0.47.10-terra.1 to v0.47.10
    • Migrate to the v0.47.10 version of CosmosSDK which is compatible with our target v0.37.4 CometBFT version.
    • Identify and resolve any conflicts with Terra Classic specific features
  • Move the oracle and stake logic to Terrad
    • Refactor the oracle module to be compatible with the updated CosmosSDK.
    • Ensure that all Terra Classic specific oracle functionality is retained.

Phase 2

Migration of Wasmd from v0.46.0-classic.1 to the mainline Wasmd v0.46.0

  • Contract’s store migration, to ensure compatibility with existing smart contracts
  • Extensive testing of contract execution and state migrations
    • Unit Testing: Update existing and create new unit tests for contract store migration logic, state migrations.
    • Integration Testing: Develop end-to-end tests simulating the entire migration process, including contract deployment, execution, and multi-contract interactions.
    • State Snapshot Testing: Import a snapshot of the current blockchain state, perform a migration dry run, verify post-migration contract states and functionality, and test rollback procedures.

Benefits

  • Improved maintainability and reduced technical debt
  • Easier adoption of future CosmosSDK updates
  • Improved security through faster implementation of upstream fixes
  • Improved interoperability with other Cosmos-based chains
  • Potential to attract more Cosmos developers to the Terra Classic ecosystem

Timeline and Milestones

Phase 1 (estimated 8 weeks):

  • Week 1: Detailed analysis and planning
  • Weeks 2-3: CometBFT unfork and integration
  • Weeks 4-5: CosmosSDK update and conflict resolution
  • Week 6: Oracle and staking logic migration to Terrad
  • Weeks 7-8: Extensive testing, community review and preparation for testnet deployment

Phase 2 (estimated 10 weeks):

  • Weeks 1-2: Wasmd migration planning and initial implementation
  • Weeks 3-6: Wasmd integration and contract compatibility testing
  • Weeks 7-8: Network-wide testing and performance tuning
  • Weeks 9-10: Final review, documentation and preparation for Testnet deployment.

Budget

Total budget requested: The payment will be divided into two phases and will be requested through two separate spending proposals.

Phase 1

Fiat value: $16,000 USD

Phase 2

Fiat value: $20,000 USD

*Total fiat value: $36,000 USD*

*Note: The actual LUNC amount for each phase will be calculated according to the real-time price of LUNC when each spending proposal is submitted.

KYC Certification

As per Proposal #12129, reviews approving code on the Terra Classic repositories must be conducted by KYCed individuals. OrbitLabs is KYCed by sollidproof.io

https://github.com/solidproof/Projects/blob/main/2024/Kien/KYC_Certificate_SolidProof_Individual_Kien.jpg
https://github.com/solidproof/Projects/blob/main/2024/Tien/KYC_Certificate_SolidProof_Individual_Tien.jpg
https://github.com/solidproof/Projects/blob/main/2024/Tuan%20Tran%20/KYC_Certificate_SolidProof_Individual_TuanTran.jpg

Progress update

We will provide weekly to bi-weekly progress reports throughout the project to ensure transparency and keep the Terra Classic community informed of all developments. In order to maximise engagement and provide real-time updates, we will be using multiple communication channels as outlined below:

Twitter Updates

  • We will provide regular updates via our official [Twitter account] (https://twitter.com/orbit__labs). These updates will cover key milestones, development progress, challenges encountered and any adjustments to the timeline. Twitter will also serve as a platform for responding to community requests and providing short updates.
  • In addition to project-specific updates, we will provide general information about blockchain developments and governance discussions related to Terra Classic.

GitHub Commits

  • All code changes will be publicly available in our official GitHub repositories. Each commit will be accompanied by a detailed commit message explaining the scope of the change, the rationale behind the change, and any related technical considerations.
  • Pull requests (PRs) will be accompanied by comprehensive documentation and will be open for community review. We encourage community developers to participate in discussions on these PRs to ensure maximum transparency and collaboration.

Community AMAs

  • At key milestones (such as the completion of major phases) we will organise Ask Me Anything (AMA) sessions. These will give the community the opportunity to ask questions directly to the development team.
  • AMAs will be hosted on Twitter Spaces. We will announce AMAs in advance via Twitter, and any key learnings from these sessions will be summarised in post-AMA updates.ill be summarized in post-AMA updates.

Medium/HackMD Blog Posts:

For deeper, more detailed updates, we will publish periodic blog posts on Medium/HackMD. These articles will serve as comprehensive reports that include project overviews, technical challenges, resolutions, and future roadmaps.

Conclusion

By removing the forked mainline modules, we aim to position Terra Classic for long-term sustainability and growth within the Cosmos ecosystem. We believe this approach balances the need for improvement with prudent risk management and community involvement.
We welcome feedback and discussion from the Terra Classic community on this proposal.

Details

  • Authors :OrbitLabs
  • Proposal Forum Link : https://commonwealth.im/terra-luna-classic-lunc/discussion/24923-proposal-removal-of-forked-modules-from-terra-classic

Vote_option_context

  • Yes: Support OrbitLabs’ proposal to remove forked modules from the Terra Classic codebase.
  • No: Oppose OrbitLabs’ proposal to remove forked modules from the Terra Classic codebase.
  • Abstain: You do not have a strong opinion and will accept the decision of the majority.
  • No with veto: You believe that this proposal is harmful and should not be implemented.
Was this article helpful?
YesNo

2 Comments

Comments are closed.

E-mail
Password
Confirm Password
QuoraTelegram