feat: eots-manager add eots verifier #360

lesterli · 2024-05-28T20:59:35Z

Summary

Add a new daemon eots-verifier that provides one gRPC API VerifyFinalitySig, the user can use it to do EOTS verification for one tx hash.

Test Plan

Build: run go build -o build/eots-verifier eots-verifier/cmd/main.go
Init: run eots-verifier init --home <home_dir>
Config: edit the config file <home_dir>/eots-verifier.conf
Start: run eots-verifier start --home <home_dir>

TODO:

integration test with op-node, Babylon node, EOTS aggregator

* Init * Update babylon-private reference * Revert "CI: Remove redundant SSH key logic (#218)"

* Add create and check FPs by chain support * Add consumer FP registration check * go lint * Improve error handling * Make chainID string * Adjust comment

…340)

…inalizedBlock()` (#347)

…ify-eots

SebastianElvis · 2024-05-29T01:31:42Z

What's the relationship between this EOTS verifier and the EOTS verifier at https://github.com/babylonchain/babylon-evm-contracts/pull/8? I was under the impression that verification only takes place at EOTS aggregator and L1/L2 contract
Why is EOTS manager providing this functionality? The EOTS manager here aims to manage the Schnorr/EOTS secret keys and secret randomness, rather than being a RPC service for verifying EOTS signatures

lesterli · 2024-05-29T02:13:05Z

It is considered an off-chain verifier that any rollup users can run locally to verify the EOTS signatures themselves to achieve fast confirmation. And the contract in babylon-evm-contracts is the on-chain verifier.
We originally thought to use the EOTSManager codebase to reuse some code. If it is confused, we can split it as a separate daemon. Wdyt?

SebastianElvis · 2024-05-29T02:18:35Z

It is considered an off-chain verifier that any rollup users can run locally to verify the EOTS signatures themselves to achieve fast confirmation. And the contract in babylon-evm-contracts is the on-chain verifier.

I see. Correct me if I'm wrong, this verifier will be a part of the EOTS aggregator?

We originally thought to use the EOTSManager codebase to reuse some code. If it is confused, we can split it as a separate daemon. Wdyt?

Yep let's move the functionality to another daemon program. In fact, I feel it might not be a part of the finality-provider repository as this targets different groups of users. If it's used in EOTS aggregator, how about we put it in the repository for EOTS aggregator?

lesterli · 2024-05-29T02:27:24Z

I see. Correct me if I'm wrong, this verifier will be a part of the EOTS aggregator?

In our design, it doesn't do the verification in the EOTS aggregator.

If it's used in EOTS aggregator, how about we put it in the repository for EOTS aggregator?

The EOTS aggregator doesn't use it, but I think we can put this gRPC in the EOTS aggregator repo.

@bap2pecs Wdyt?

bap2pecs · 2024-05-29T13:42:07Z

In fact, I feel it might not be a part of the finality-provider repository as this targets different groups of users

@SebastianElvis I think this part makes sense. so it will be confusing if the user of the chain has to run a program in the FP repo. I am in for the move as long as we don't need to share lots of code from this FP repo.

I am fine to create a new repo finality-verifier or just another daemon program within the same repo

I think a daemon should work b/c it's technically still “finality" related. and the benefit is we can reuse the CI / test frameworks here

lesterli · 2024-05-29T14:04:40Z

I think we can put this gRPC in the EOTS aggregator repo.

Correct it.

Their target user is different, especially if the aggregator functions as a P2P network.

I am fine to create a new repo finality-verifier or just another daemon program within the same repo

It makes sense.

SebastianElvis · 2024-05-29T22:58:02Z

Yep having a new daemon for EOTS verifier sounds good to me. @gitferry wdyt?

bap2pecs · 2024-05-29T23:02:13Z

rollup users will be running EOTS verifier

EOTS aggregator is run by a diff group of people

but for you q offline, EOTS aggregator will still verify the EOTS before storing in its database

gitferry · 2024-05-30T05:48:28Z

Had an offline discussion with @SebastianElvis. A separate daemon for eots-verifier under the finality-provider repo sounds good to me 👍

bap2pecs · 2024-05-31T15:57:28Z

eots-verifier/cmd/daemon/flags.go

+
+const (
+	homeFlag        = "home"
+	forceFlag       = "force"


what's force?

bap2pecs · 2024-05-31T16:01:42Z

eots-verifier/config/config.go

+	defaultRollupRPC     = "http://127.0.0.1:8545"
+	defaultRollupChainId = "42069"


called rollup is too specific. we should call it defaultConsumerChainRPC

also default values should be sth that can work most of the time

but it's almost certain that the last 4 values should be changed when we run the daemon. so we should just remove those and only rely on the config file

bap2pecs · 2024-05-31T16:05:17Z

eots-verifier/config/config.go

+	RpcListener   string `long:"rpclistener" description:"the listener for RPC connections, e.g., 127.0.0.1:1234"`
+	BabylonRPC    string `long:"babylon_rpc" description:"connect to the Babylon RPC service"`
+	EotsAggRPC    string `long:"eots_agg_rpc" description:"connect to the EOTS Aggregator RPC service"`
+	RollupRPC     string `long:"rollup_rpc" description:"connect to the Rollup RPC service"`


Rollup -> consumer

bap2pecs · 2024-05-31T16:09:25Z

eots-verifier/proto/eots_verifier.proto

+
+message VerifyFinalitySigRequest {
+    // block_number is the block which need to be verified
+    uint64 block_number = 1;


per my comments below, we need to also pass in the tx hash to be verified

also per design 3 in https://www.notion.so/snapchain/Security-Requirements-1076b96c44144e82a61b4ed393364399, we might ask FP to sign a range of blocks. so instead of verify

bap2pecs · 2024-05-31T16:23:09Z

eots-verifier/service/server.go

+func (s *Server) VerifyFinalitySig(ctx context.Context, req *proto.VerifyFinalitySigRequest) (
+	*proto.VerifyFinalitySigResponse, error) {
+	height := req.BlockNumber
+	l2Block, err := s.rollupClient.BlockByNumber(ctx, new(big.Int).SetUint64(height))


i think we shouldn't trust getting the data from the RPC. because we can't guarantee the RPC returns the same block that contains the same tx as the block the user accepts

let's think of the goal of the verifier program: to help a user to build up confidence that a tx he observes is in a block that has enough valid EOTS sigs

so the minimum input should be the tx hash. it has to be something that doesn't allow you to change this tx. block number itself doesn't provide the guarantee.

the flow should be:

user obtains the tx hash

user queries the RPC to get the block that contains the tx

user gets all data (e.g. tx list) from the RPC

user gets the signatures from the aggregator

user gets the FP VP ...

...

user verifies the EOTS signatures

add block number can ensure more security: to help a user to build up confidence that a tx he observes is in a specific block that has enough valid EOTS sigs

the flow should be:

user obtains the tx hash

user queries the RPC to get the block that contains the tx

user check if the block number matches

user gets all data (e.g. tx list) from the RPC

user gets the signatures from the aggregator

user gets the FP VP ...

...

user verifies the EOTS signatures

bap2pecs · 2024-05-31T16:30:37Z

eots-verifier/service/server.go

+	return bbnRes.FinalityProviders, totalPower, nil
+}
+
+func (s *Server) calculateValidPower(ctx context.Context, msg []byte, fpList []*bsctypes.FinalityProviderResponse, eotsInfos []*eotsservice.EOTSInfoResponse) (uint64, error) {


calculateTotalPowerFromEotsVerifiedFps

bap2pecs · 2024-05-31T16:31:52Z

eots-verifier/service/server.go

+	for _, fp := range fpList {
+		for _, info := range eotsInfos {


why are there two levels of for loops?

bap2pecs · 2024-07-07T16:13:13Z

Had an offline discussion with @SebastianElvis. A separate daemon for eots-verifier under the finality-provider repo sounds good to me 👍

per my conversation w @SebastianElvis recently, it's probably better to put this in the https://github.com/babylonchain/babylon-da-sdk repo, making it kind of like a demo case for using the SDK as well

If there is some code sharing needed, we can always import from this FP repo

SebastianElvis · 2024-07-08T01:21:05Z

Yes, putting the EOTS verifier under a new folder of the babylon-da-sdk repo seems to be a proper way

maurolacy and others added 10 commits May 21, 2024 17:05

Consumer chain finality provider (#276)

db7cf8a

* Init * Update babylon-private reference * Revert "CI: Remove redundant SSH key logic (#218)"

Consumer FP registration test (#278)

a4b81d0

* Add create and check FPs by chain support * Add consumer FP registration check * go lint * Improve error handling * Make chainID string * Adjust comment

fix flaky e2e test

37fd560

cd: Allows base/consumer-chain-support branch to run push_docker job (#…

a372764

…340)

feat: support op-stack based L2 consumer chain (#348)

597fc38

refactor: QueryLatestFinalizedBlocks(count uint64) -> `QueryLatestF…

30df90e

…inalizedBlock()` (#347)

merge updates from dev (#355)

623964e

eots verifier

ef320d1

check if enable verifier

39e1304

Merge branch 'base/consumer-chain-support' into feat/eots-manager-ver…

028409a

…ify-eots

lesterli requested review from gitferry, SebastianElvis and bap2pecs May 29, 2024 00:03

lesterli added 2 commits May 30, 2024 15:21

revert for eotsmanager

a55a471

new daemon for eots verifier

4af0a1e

bap2pecs suggested changes May 31, 2024

View reviewed changes

update for comments

874693f

SebastianElvis force-pushed the base/consumer-chain-support branch from 623964e to 2cc4a79 Compare June 5, 2024 12:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: eots-manager add eots verifier #360

feat: eots-manager add eots verifier #360

lesterli commented May 28, 2024 •

edited

Loading

SebastianElvis commented May 29, 2024

lesterli commented May 29, 2024

SebastianElvis commented May 29, 2024

lesterli commented May 29, 2024

bap2pecs commented May 29, 2024 •

edited

Loading

lesterli commented May 29, 2024

SebastianElvis commented May 29, 2024

bap2pecs commented May 29, 2024

gitferry commented May 30, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs May 31, 2024

bap2pecs commented Jul 7, 2024

SebastianElvis commented Jul 8, 2024

		defaultRollupRPC = "http://127.0.0.1:8545"
		defaultRollupChainId = "42069"

feat: eots-manager add eots verifier #360

Are you sure you want to change the base?

feat: eots-manager add eots verifier #360

Conversation

lesterli commented May 28, 2024 • edited Loading

Summary

Test Plan

SebastianElvis commented May 29, 2024

lesterli commented May 29, 2024

SebastianElvis commented May 29, 2024

lesterli commented May 29, 2024

bap2pecs commented May 29, 2024 • edited Loading

lesterli commented May 29, 2024

SebastianElvis commented May 29, 2024

bap2pecs commented May 29, 2024

gitferry commented May 30, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bap2pecs commented Jul 7, 2024

SebastianElvis commented Jul 8, 2024

lesterli commented May 28, 2024 •

edited

Loading

bap2pecs commented May 29, 2024 •

edited

Loading