Merge branch 'main' into chore/add-block-results-query

babylonlabs-io · Oct 10, 2024 · 832f2f1 · 832f2f1
2 parents 1bbd526 + 0b203a6
commit 832f2f1
Show file tree

Hide file tree

Showing 20 changed files with 2,418 additions and 9,753 deletions.
diff --git a/.github/workflows/backport.yml b/.github/workflows/backport.yml
@@ -0,0 +1,38 @@
+# Adapted from https://github.com/marketplace/actions/backporting
+#
+# Usage: 
+#   - Let's say you want to backport a pull request on a branch named `production`.
+#   - Then label it with `backport production`.
+#   - That's it! When the pull request gets merged, it will be backported to 
+#     the `production` branch. If the pull request cannot be backported, a comment 
+#     explaining why will automatically be posted.
+#
+# Note: multiple backport labels can be added. For example, if a pull request 
+#       has the labels `backport staging` and `backport production` it will be 
+#       backported to both branches: `staging` and `production`.
+name: Backport
+on:
+  pull_request_target:
+    types:
+      - closed
+      - labeled
+
+jobs:
+  backport:
+    name: Backport
+    runs-on: ubuntu-latest
+    # Only react to merged PRs for security reasons.
+    # See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target.
+    if: >
+      github.event.pull_request.merged
+      && (
+        github.event.action == 'closed'
+        || (
+          github.event.action == 'labeled'
+          && contains(github.event.label.name, 'backport')
+        )
+      )
+    steps:
+      - uses: tibdex/backport@v2
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -37,17 +37,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
 ## Unreleased
 
-### Bug Fixes
+### Improvements
 
-* [#140](https://github.com/babylonlabs-io/babylon/pull/140) Removed `unbonding`
-and add `verified` to delegation status parse `NewBTCDelegationStatusFromString`.
+* [#148](https://github.com/babylonlabs-io/babylon/pull/148) Add block results query
+
+## v0.12.0
 
 ### State Machine Breaking
 
 * [#132](https://github.com/babylonlabs-io/babylon/pull/132) Add CosmWasm parameters
 update during v1 upgrade handler.
+* [#142](https://github.com/babylonlabs-io/babylon/pull/142) Remove signed finality providers
+insert from the v1 upgrade handler.
 
-### Misc Improvements
+### Improvements
 
 * [#130](https://github.com/babylonlabs-io/babylon/pull/130) Fix bugs in the
 transaction fee refunding mechanism for covenant signatures and finality signatures
@@ -57,10 +60,8 @@ refund transaction fee for certain transactions from protocol stakeholders
 pre-approval flow.
 * [#138](https://github.com/babylonlabs-io/babylon/pull/138) Intercept staking module
 messages inside `authz.MsgExec`.
-
-### Improvements
-
-* [#148](https://github.com/babylonlabs-io/babylon/pull/148) Add block results query
+* [#146](https://github.com/babylonlabs-io/babylon/pull/146) Add property status as a filter
+to BTC delegations rest request `QueryBTCDelegationsRequest`.
 * [#144](https://github.com/babylonlabs-io/babylon/pull/144) Add new finality provider events
 * [#131](https://github.com/babylonlabs-io/babylon/pull/131) Add new staking events
 * [#113](https://github.com/babylonlabs-io/babylon/pull/113) Add multibuild binary
@@ -70,6 +71,8 @@ for upgrade handler `testnet` and `mainnet`.
 
 * [#141](https://github.com/babylonlabs-io/babylon/pull/141) Generate voting
 power events only once when reaching covenant committee quorum
+* [#140](https://github.com/babylonlabs-io/babylon/pull/140) Removed `unbonding`
+and add `verified` to delegation status parse `NewBTCDelegationStatusFromString`.
 
 ## v0.11.0
 

diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md
@@ -1,12 +1,11 @@
 # Release Process
 
-- [Release Process](#release-process)
-  - [Breaking Changes](#breaking-changes)
-  - [Release Procedure](#release-procedure)
-    - [Creating a new release branch](#creating-a-new-release-branch)
-    - [Cutting a new release](#cutting-a-new-release)
-    - [Tagging Procedure](#tagging-procedure)
-  - [Patch release Procedure](#patch-release-procedure)
+- [Breaking Changes](#breaking-changes)
+- [Release Procedure](#release-procedure)
+  - [Creating a new release branch](#creating-a-new-release-branch)
+  - [Cutting a new release](#cutting-a-new-release)
+  - [Tagging Procedure](#tagging-procedure)
+- [Patch Release Procedure](#patch-release-procedure)
 
 This document outlines the release process for the Babylon node (babylond)
 
@@ -119,10 +118,13 @@ A _patch release_ is an increment of the patch number (eg: `v10.0.0` → `v10.0.
 circumstances .**_
 
 Updates to the release branch should come from `main` by backporting PRs
-(usually done by automatic cherry pick followed by a PRs to the release branch).
-The backports must be marked using `backport/Y` label in PR for main.
-It is the PR author's responsibility to fix merge conflicts and
-ensure CI passes.
+(usually done by automatic cherry pick followed by a PR to the release branch).
+The backports must be marked using `backport release/v0.Y.x` label in PR for
+`main`, where `release/v0.Y.x` is the name of the release branch. It is the PR
+author's responsibility to fix merge conflicts, update changelog entries, and
+ensure CI passes. If a PR originates from an external contributor, a member of
+the stewarding team assumes responsibility to perform this process instead of
+the original author.
 
 After the release branch has all commits required for the next patch release:
 * Create a new annotated git tag in the release

diff --git a/app/include_upgrade_mainnet.go b/app/include_upgrade_mainnet.go
@@ -15,7 +15,6 @@ func init() {
 		FinalityParamStr:      mainnet.FinalityParamStr,
 		CosmWasmParamStr:      mainnet.CosmWasmParamStr,
 		NewBtcHeadersStr:      mainnet.NewBtcHeadersStr,
-		SignedFPsStr:          mainnet.SignedFPsStr,
 		TokensDistributionStr: mainnet.TokensDistributionStr,
 	})}
 }
diff --git a/app/include_upgrade_testnet.go b/app/include_upgrade_testnet.go
@@ -16,7 +16,6 @@ func init() {
 		FinalityParamStr:      testnet.FinalityParamStr,
 		CosmWasmParamStr:      testnet.CosmWasmParamStr,
 		NewBtcHeadersStr:      testnet.NewBtcHeadersStr,
-		SignedFPsStr:          testnet.SignedFPsStr,
 		TokensDistributionStr: testnet.TokensDistributionStr,
 	})}
 }
diff --git a/app/upgrades/v1/README.md b/app/upgrades/v1/README.md
@@ -4,18 +4,14 @@ Babylon launched as Phase-1 without a cosmos chain running
 to collect BTC staking prior to decentralize the finality provider
 set of operators. The first upgrade of Babylon chain to start
 receiving BTC delegations will include the BTC headers created
-during Phase-1 and upgrade, finality providers registered in the
-dashboard, tokens distribution for the active users and operators
-that participated and need to finish their actions and update of
-parameters for `x/finality` and `x/btcstaking` modules.
+during Phase-1 and upgrade, tokens distribution for the active users
+and operators that participated and need to finish their actions and
+update of parameters for `x/finality` and `x/btcstaking` modules.
 
 ## Testnet vs Mainnet
 
 Babylon upgrade data will be different for mainnet and testnet,
-finality providers should not use the same keys for mainnet and testnet.
-So to register himself and test, the finality providers will use two
-different registrations one for mainnet and another for testnet. The
-BTC Headers also are different as the Bitcoin mainnet and signet produces
+The BTC Headers are different as the Bitcoin mainnet and signet produces
 different block headers. So, the upgrade data will be divided into 2
 `app/upgrades/v1`:
 
@@ -34,10 +30,9 @@ The upgrade data was left as string to make it easier for `devnet` testing
 where it is needed to replace the data files, and would be harder to create
 the data files if it used actual go structures to generate the data.
 
-This upgrade loads 6 JSONs from strings in different files.
+This upgrade loads 5 JSONs from strings in different files.
 
 - BTC Headers at `./data_btc_headers.go`
-- Finality Providers signed messages at`./data_signed_fps.go`
 - Tokens distribution at `./data_token_distribution.go`
 - BTC Staking Parameters `./btcstaking_params.go`
 - Finality Parameters `./finality_params.go`
@@ -75,20 +70,6 @@ echo "package signetlaunch
 const NewBtcHeadersStr = \`$btcHeadersJson\`" > $GO_BTC_HEADERS_PATH
 ```
 
-### Signed Create Finality Provider
-
-For BTC stakers to stake during Phase-1 it is needed to have finality
-providers. Babylon created a repository to publicly store this information
-inside [networks](https://github.com/babylonlabs-io/networks) repository.
-Inside the bbn-1 mainnet all the finality providers that wanted to be available
-for BTC staking since the beginning would need to
-[register](https://github.com/babylonlabs-io/networks/blob/main/bbn-1/finality-providers/README.md)
-theirselves in the registry.
-For the transition from Phase-1 to Phase-2, registered finality providers in
-Phase-1 will need to provider a signed
-[MsgCreateFinalityProvider](../../../x/btcstaking/types/tx.pb.go#38) as a
-json file message inside the networks repository registry.
-
 ### Tokens distribution
 
 During the upgrade, some tokens will be distributed so users and operators can

diff --git a/app/upgrades/v1/data_signed_fps_test.go b/app/upgrades/v1/data_signed_fps_test.go