Releases: regen-network/regen-ledger
v5.1.4
v5.1.3
Changelog
- 67240f6 chore: Update changelog for v5.1.3 (#2193)
- 6755857 chore: version bump for ledger-cosmos-go (backport #2191) (#2192)
- b498ace feat(docs): add sitemap (backport #2066) (#2067)
- 245a01f docs: add regen faucet page link (backport #2052) (#2055)
- d734e31 docs: add note about credit type to credit class tutorial (backport #2026) (#2028)
- 33a70da docs: update governance proposal tutorial (backport #1991) (#2025)
- f8235c6 docs: update company title from inc to pbc (backport #2009) (#2010)
- ade01bb docs: add copy to clip for code snippets (backport #1981) (#1986)
- 1b5f5d6 docs: add note about json-ld filepath (backport #1983) (#1984)
- ecbdf62 docs: add and update introduction and get started (backport #1976) (#1980)
- bf8a9eb docs: credit class, project, and batch tutorial (backport #1965) (#1977)
- f9cb9cd docs: add update for min-gas-prices in local-testnet tutorial (backport #1970) (#1971)
- dd5448a docs: upgrade vuepress to v2 (backport #1958) (#1959)
v5.1.2
v5.1.1
v5.1.0
This upgrade includes a few fixes, improvements, and migrations related to the ecocredit module as well as an update to the latest patch release of Cosmos SDK (v0.46.11).
Cosmos SDK Update
Regen Ledger v5.0 included an update to the latest version of Cosmos SDK (v0.46.7) using a forked version of Cosmos SDK that adds amino support for the new gov and group modules (a fix that was officially made available in v0.47).
Since the release of Regen Ledger v5.0, several patch releases have been made available. In particular, the v0.46.8 patch release included improvements to the store and therefore a coordinated upgrade is recommended.
At the time of the proposed upgrade, Cosmos SDK will be updated to the latest patch release (v0.46.11) using a forked version with amino support for the gov and group modules.
Credit Batch Metadata
The schema for metadata referenced within a credit batch has been updated. This is part of a larger effort to provide a consistent standard for all credit batches issued through Regen Registry and to clearly distinguish between data that needs to be anchored on chain and data that is specific to our web application.
Updating to the new schema requires updating the metadata field within each credit batch. Credit batches on Regen Ledger are sealed by default and cannot be updated via state transition functions. This means that an on-chain governance process is required to update the metadata of credits that have already been issued.
At the time of the proposed upgrade, the metadata field within each credit batch will be updated to a new IRI referencing the data stored using the updated schema. The state migration for these changes can be viewed here.
Basket Fixes / NCT Basket
In preparation for the launch of the NCT liquidity pool on Osmosis, the NCT basket was created on Regen Mainnet. At the time of creation, an issue was discovered with setting date criteria using the “years in the past” option. This option sets a requirement on what credits can be put into the basket based on the year of the credit batch start date (i.e. 10 years in the past would mean only credits with a batch start date year of 2013 or later). This option was ignored during basket creation and a fix has been added to prevent this from happening in the future.
In addition, a user error was made at the time of creation and the disable auto-retire option was not set. The default setting when creating a basket is for all credits to be retired when credits are taken from the basket. The intention of the NCT basket is to enable NCT eligible credits to move freely between Polygon (Toucan contracts) and Regen.
At the time of the proposed upgrade, the NCT basket will be updated to include a date criteria with years in the past set to 10 years (according to the NCT standard) and the disable auto-retire option will be set to true (allowing credits to be taken from the basket in a tradable state). The state migration for these changes can be viewed here.
In addition, there have been some discussions about updating the NCT standard (specifically the date criteria). As a result, we have included a new governance message that will allow the date criteria of a basket to be updated through a network-wide governance vote.
Updated Bridge Events
The Toucan-Regen bridge is undergoing a final round of audits and testing. During this process, a few opportunities to simplify event processing were discovered and therefore new event properties have been added to the bridge events within the ecocredit module. The launch of the bridge is not dependent upon these changes.
Changelog
For a full list of changes since Regen Ledger v5.0, please see CHANGELOG.md.
Validator Upgrade Guide
An upgrade guide for validators and node operators is available at Upgrade Guide v5.1.
v5.1.0-rc2
The second release candidate (RC2) for Regen Ledger v5.1.0.
The following changes have been made since the first release candidate:
x/ecocredit
- #1864 Add
MsgUpdateDateCriteriato basket submodule
v5.1.0-rc1
The first release candidate (RC1) for Regen Ledger v5.1.0.
This upgrade includes a few fixes, improvements, and migrations related to the ecocredit module as well as an update to the latest patch release of Cosmos SDK (v0.46.11).
Cosmos SDK Update
Regen Ledger v5.0 included an update to the latest version of Cosmos SDK (v0.46.7) using a forked version of Cosmos SDK that adds amino support for the new gov and group modules (a fix that was officially made available in v0.47).
Since the release of Regen Ledger v5.0, several patch releases have been made available. In particular, the v0.46.8 patch release included improvements to the store and therefore a coordinated upgrade is recommended.
At the time of the proposed upgrade, Cosmos SDK will be updated to the latest patch release (v0.46.11) using a forked version with amino support for the gov and group modules.
Credit Batch Metadata
The schema for metadata referenced within a credit batch has been updated. This is part of a larger effort to provide a consistent standard for all credit batches issued through Regen Registry and to clearly distinguish between data that needs to be anchored on chain and data that is specific to our web application.
Updating to the new schema requires updating the metadata field within each credit batch. Credit batches on Regen Ledger are sealed by default and cannot be updated via state transition functions. This means that an on-chain governance process is required to update the metadata of credits that have already been issued.
At the time of the proposed upgrade, the metadata field within each credit batch will be updated to a new IRI referencing the data stored using the updated schema. The state migration for these changes can be viewed here.
Basket Fixes / NCT Basket
In preparation for the launch of the NCT liquidity pool on Osmosis, the NCT basket was created on Regen Mainnet. At the time of creation, an issue was discovered with setting date criteria using the “years in the past” option. This option sets a requirement on what credits can be put into the basket based on the year of the credit batch start date (i.e. 10 years in the past would mean only credits with a batch start date year of 2013 or later). This option was ignored during basket creation and a fix has been added to prevent this from happening in the future.
In addition, a user error was made at the time of creation and the disable auto-retire option was not set. The default setting when creating a basket is for all credits to be retired when credits are taken from the basket. The intention of the NCT basket is to enable NCT eligible credits to move freely between Polygon (Toucan contracts) and Regen.
At the time of the proposed upgrade, the NCT basket will be updated to include a date criteria with years in the past set to 10 years (according to the NCT standard) and the disable auto-retire option will be set to true (allowing credits to be taken from the basket in a tradable state). The state migration for these changes can be viewed here.
Updated Bridge Events
The Toucan-Regen bridge is undergoing a final round of audits and testing. During this process, a few opportunities to simplify event processing were discovered and therefore new event properties have been added to the bridge events within the ecocredit module. The launch of the bridge is not dependent upon these changes.
Changelog
For a full list of changes since Regen Ledger v5.0, please see CHANGELOG.md.
Validator Upgrade Guide
An upgrade guide for validators will be made available when the official release has been tagged.
v5.0.0
New Features
The new features made available in Regen Ledger v5.0 are as follows:
DAO support via Group Accounts
Regen Ledger now includes the group module made available in Cosmos SDK v0.46. The group module started out as a custom module built within the Regen Ledger repository and has since been added to Cosmos SDK as a core module refined and maintained by the Cosmos SDK core developers. The group module enables the creation and management of on-chain multisig accounts and voting for message execution based on configurable decision policies.
What does this mean within the context of Regen Ledger functionality? All entities on a Regen Ledger chain can now be managed by a group account. For example, the role of the credit class admin can be assigned to a group account and the group can create and update decision policies for the execution of messages that are restricted to the role of the credit class admin. This example can be reapplied to all on-chain entities. In the ecocredit module, a group account could be assigned the role of credit class creator, credit class issuer, project admin, and/or basket curator, and in the data module, a group account could be assigned the role of resolver manager.
The group module also enables any individual or group of individuals to create and manage a group account independent of the predefined roles for on-chain entities. A prime example being community staking DAOs, which can now be managed by group accounts, therefore enabling the creation and management of decision policies around the execution of messages on behalf of a community staking DAO and the updating of members within the community staking DAO. Another use case of the group module is two-factor authentication whereby an individual uses a group account as their primary account that requires them to sign-off on the execution of messages using multiple devices (an account on each device).
For more information about the group module, check out the group module documentation.
Message-Based Governance Proposals
Regen Ledger now includes the latest version of the gov module (v1) made available in Cosmos SDK v0.46. The previous version of the gov module (v1beta1) is still wired up in the application for backwards compatibility and to support application modules that have not yet been updated to utilize the latest version. The main feature in the latest version is message-based governance proposals. In combination with the authz module and the group module, message-based governance proposals unlock new opportunities for governance.
Governance proposals have historically been used for updating a specific set of governance parameters defined within each application module. Message-based governance proposals are similar in that they update governance parameters but those parameters are now more loosely defined, i.e. governance parameters are simply state and no longer need to be defined specifically as a governance parameter. Messages that update such state are implemented with restrictions on which account can call the message (similar to how a credit class admin is the only account with permission to update a credit class) but the account in this case is the gov module account.
With message-based governance proposals, any message can be submitted within the proposal to be executed on behalf of the gov module. Using the authz module alongside message-based governance proposals, it's now possible for a governance proposal to be submitted that would authorize another account to execute a specific message on behalf of the gov module account. The other account could be a group account representing a group of individuals that have expertise related to the state being managed. For example, a community staking DAO made up of a group of scientists could be granted authorization to add credit types and credit types could then be added via the voting process of the group.
All governance parameters within the ecocredit module have been updated to support message-based governance proposals. The data module does not include any governance parameters. All other application modules that are imported and have not yet been updated to support message-based governance proposals continue to work the same with what are now called "legacy" proposals.
For more information about the gov module, check out the gov module documentation.
Interchain Accounts
Two new modules have been added to support interchain accounts. Interchain accounts enables cross-chain account management built on IBC. One of the modules is an application module built and maintained by the IBC team within the ibc-go repository (the ica module) and the other is an application module built and maintained by the RND team within the regen-ledger repository (the intertx module).
Interchain accounts are accounts controlled programmatically by counterparty chains via IBC packets. Unlike a traditional account, an interchain account does not have a private key and therefore does not sign transactions. The account is registered on a "host chain" via a "controller chain" and the controller chain sends instructions (IBC packets with Cosmos SDK messages) to the host chain that the interchain account then executes.
The ica module has two submodules (host and controller). The host submodule enables a Regen Ledger chain to act as a "host chain" and the controller submodule enables a Regen Ledger chain to act as a "controller chain". The host and controller submodules will not be enabled following the upgrade of an existing Regen Ledger chain and therefore each will require an on-chain governance proposal to enable. Which messages allowed to be executed by interchain accounts will also need to be added to an allowed_messages parameter in the host submodule with subsequent governance proposals.
The intertx module includes functionality to support the controller submodule, enabling the registration of interchain accounts and submitting transactions to be executed on a host chain.
For more information about interchain accounts, check out the interchain accounts documentation.
Relayer Incentivization
The fee module is a self-contained middleware module that extends the base IBC application module. The fee module was designed as an incentivization mechanism to help cover the operational costs of running a relayer (i.e. running full nodes to query transaction proofs and paying for transaction fees associated with IBC packets).
There are three fees within the fee model, one for receiving the packet, one for acknowledging the packet, and one for timeouts. The fees are held in escrow until the packet is either successful or times out. In the case of a successful packet, the timeout fee will be reimbursed, and in the case of an unsuccessful packet, the receiving and acknowledging fee will be reimbursed.
The first version of the fee module only supports incentivization of new channels and existing channels will need to wait for additional functionality to support upgradeability. Using the fee middleware with IBC transactions is optional and acts more like a "tip". End users can manually incentivize IBC packets using the CLI and client developers can leverage the gRPC endpoints to integrate relayer fees within their application.
For more information about fee middleware, check out the fee middleware documentation.
Additional Changes
SDK Module Manager
Regen Ledger has historically been using a custom module manager within the application wiring. Regen Ledger v5.0 migrates from the custom module manager to the latest version of the Cosmos SDK module manager and updates the ecocredit module and data module accordingly.
gRPC Error Codes
A community member reported that the gRPC error codes for queries were not being reported correctly, in some cases the error code was Unknown and in other cases the error code did not match the standard gRPC error codes. Not all projects building on Regen Ledger will use the error messages provided by Regen Ledger and may choose to create their own error messages based on the error codes returned. To ensure we are providing a good developer experience, we have fixed and updated gRPC error codes to return the expected gRPC error codes.
Experimental Build
Following Regen Ledger v4.0, and now with Regen Ledger v5.0, all experimental features that were being developed within the Regen Ledger codebase have been stablilized and included in the stable application build. The experimental application build option has therefore been removed. We will consider a separate release that includes CosmWasm that will be used to reboot Hambach Testnet if developers are wanting to experiment with the latest features alongside CosmWasm contracts, otherwise Hambach Testnet will continue running with support for CosmWasm contracts on the experimental build of Regen Ledger v4.0.
Changelog
For a full list of changes since Regen Ledger v4.1, please see CHANGELOG.md.
Validator Upgrade Guide
An upgrade guide for validators and node operators is available at Upgrade Guide v5.0.
Developer Migration Guide
A migration guide for application developers is available at Migration Guide v5.0.