Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement core btc handling logic #70

Merged
merged 4 commits into from
Jul 27, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 13 additions & 1 deletion app/app.go
Original file line number Diff line number Diff line change
Expand Up @@ -336,7 +336,19 @@ func NewBabylonApp(

// TODO for now use mocks, as soon as Checkpoining and lightClient will have correct interfaces
// change to correct implementations
app.BtcCheckpointKeeper = btccheckpointkeeper.NewKeeper(appCodec, keys[btccheckpointtypes.StoreKey], keys[btccheckpointtypes.MemStoreKey], app.GetSubspace(btccheckpointtypes.ModuleName), btccheckpointtypes.MockBTCLightClientKeeper{}, btccheckpointtypes.MockCheckpointingKeeper{})
app.BtcCheckpointKeeper =
btccheckpointkeeper.NewKeeper(
appCodec,
keys[btccheckpointtypes.StoreKey],
keys[btccheckpointtypes.MemStoreKey],
app.GetSubspace(btccheckpointtypes.ModuleName),
btccheckpointtypes.MockBTCLightClientKeeper{},
btccheckpointtypes.MockCheckpointingKeeper{},
// TODO decide on proper values for those constants, also those should be taken
// from some global config
6,
10,
)
app.CheckpointingKeeper = checkpointingkeeper.NewKeeper(appCodec, keys[checkpointingtypes.StoreKey], keys[checkpointingtypes.MemStoreKey], app.EpochingKeeper, app.GetSubspace(checkpointingtypes.ModuleName))
// create evidence keeper with router
evidenceKeeper := evidencekeeper.NewKeeper(
Expand Down
25 changes: 25 additions & 0 deletions proto/babylon/btccheckpoint/btccheckpoint.proto
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,23 @@ message SubmissionKey {
repeated TransactionKey key = 1;
}

enum EpochStatus {
option (gogoproto.goproto_enum_prefix) = false;
// SUBMITTED Epoch is in submitted state when at least on checkpoint from it
// is included in bitcoin
EPOCH_STATUS_SUBMITTED = 0 [(gogoproto.enumvalue_customname) = "Submitted"];
// CONFIRMED Epoch is in confirmed state when at least on checkpoint from it
// is included in bitcoin and at least k-deep on main chain
EPOCH_STATUS_CONFIRMED = 1 [(gogoproto.enumvalue_customname) = "Confirmed"];
// FINALIZED Epoch is in confirmed state when at least on checkpoint from it
// is included in bitcoin and at least w-deep on main chain
EPOCH_STATUS_FINALIZED = 2 [(gogoproto.enumvalue_customname) = "Finalized"];
// SIGNED Epoch does not have any submissions or all of its submission are not on
// main chain
EPOCH_STATUS_SIGNED = 3 [(gogoproto.enumvalue_customname) = "Signed"];
}


// TODO: Determine if we should keep any block number or depth info.
// On one hand it may be usefull to determine if block is stable or not, on other
// depth/block number info, without context (i.e info about chain) is pretty useless
Expand All @@ -40,6 +57,8 @@ message SubmissionData {
// message, and store only those. Another point is that it is not that simple
// to recover sender of btc tx.
repeated bytes btctransaction = 2;

uint64 epoch = 3;
}

// Data stored in db and indexed by epoch number
Expand All @@ -48,5 +67,11 @@ message EpochData {
// List of all received checkpoints during this epoch, sorted by order of
// submission.
repeated SubmissionKey key = 1;

// Current state of epoch.
EpochStatus status = 2;

// Required to comunicate with checkpoint module about checkpoint status
bytes raw_checkpoint = 3;
}

35 changes: 35 additions & 0 deletions x/btccheckpoint/keeper/hooks.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
package keeper

import (
ltypes "github.com/babylonchain/babylon/x/btclightclient/types"
etypes "github.com/babylonchain/babylon/x/epoching/types"
sdk "github.com/cosmos/cosmos-sdk/types"
)

// Helper interface to be sure Hooks implement both epoching and light client hooks
type HandledHooks interface {
ltypes.BTCLightClientHooks
etypes.EpochingHooks
}

type Hooks struct {
k Keeper
}

var _ HandledHooks = Hooks{}

func (k Keeper) Hooks() Hooks { return Hooks{k} }

func (h Hooks) AfterBTCRollBack(ctx sdk.Context, headerInfo *ltypes.BTCHeaderInfo) {
h.k.OnTipChange(ctx)
}

func (h Hooks) AfterBTCRollForward(ctx sdk.Context, headerInfo *ltypes.BTCHeaderInfo) {
h.k.OnTipChange(ctx)
}
Comment on lines +23 to +29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is what we discussed at length about using events vs using queries with @vitsalis. We emit events that, with the right bookkeeping could be used to decide the status of the submissions without doing any queries against the light client, but the option to do just queries and ignore the events is also there. Both are fine; events are more efficient more complex to code (need to track the status of individual submissions), while queries are simple but lead to more wasted computation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So basically btccheckpoint could build view of the light client main chain ? Sounds like a good optimization ! I would start here with queries, and do this a bit later when we will have already working system (with more tests etc.).Imo at this point some wasted is not a big deal.


func (h Hooks) AfterEpochBegins(ctx sdk.Context, epoch uint64) {}

func (h Hooks) AfterEpochEnds(ctx sdk.Context, epoch uint64) {}

func (h Hooks) BeforeSlashThreshold(ctx sdk.Context, valSet etypes.ValidatorSet) {}
Loading