layr-labs / eigensdk-go Goto Github PK

@ian-shim made a bunch of upgrades to our tx-manager->wallet->signer/fireblocks pipeline.

Need to update the diagram in chainio/txmgr/simple-tx-manager-flow.png to reflect this new architecture.

Also need to think through whether getNoSendTxOpts() should still be in txmgr, or should be somewhere else (wallet? maybe in the writer clients directly? unsure about this part..)

Right now, the entire repository is versioned together.
If there is a desired patch for one package, but that version has an undesired update on another package, I cannot make an upgrade.
Ideally, each package is versioned separately, so that developers can upgrade specific packages.

Some AVSs might need to communicate via p2p network. Let's just write a simple implementation, probably using libp2p. Have a look at the avalanche and optimism implementations for examples.

Is your feature request related to a problem? Please describe.
Need a tool to batch key import private keys and convert into encrypted keys files with password which can be used for testing

Note: This utility should be only used for testing

Describe the solution you'd like
This should create (ecdsa/bls)

• Input a private.keys.txt file which has one key per line
• A folder which has all the encrypted json files
• A private.keys.loc.txt file with one filename for each private key
• A passwords.txt file with one password for each of those keys

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Tried to generate ecdsa_keys and it appears not all private_keys are valid using engkeygen tool

To Reproduce
Tried to generate ecdsa_keys some of which are invalid length command used: ./engkeygen generate --key-type ecdsa --num-keys 400

Expected behavior
ECDSA keys generated are valid private keys

Screenshots

OS details
mac OS 13.5.1

Additional context
Generated Files
312c4a0e-6f86-11ee-a883-fa9e2728ee37.zip

We shouldn't have used type aliases in types (see for example OperatorId). See quote below.

Problem it creates is that when another pkg uses the sdk and calls a function which returns an Aliased type, vscode (and probably other editors?) show the returned type as the underneath type definition (instead of the type alias name).

So for eg getOperatorsAvsStateAtBlock will show

instead of its actual definition in the sdk as

Note the key type is Bytes32 instead of OperatorId, so it lost its semantics.

Type aliases are not meant for everyday use. They were introduced to support gradual code repair while moving a type between packages during large-scale refactoring. Codebase Refactoring (with help from Go) covers this in detail.

From https://yourbasic.org/golang/type-alias/ (and see the linked https://go.dev/talks/2016/refactor.article)

Describe the bug

Right now we throw a generic error message when image is invalid - https://github.com/Layr-Labs/eigensdk-go/blob/master/types/operator_metadata.go#L56

We should throw specific error that only .png is allowed and other specific error

To Reproduce

Expected behavior

Screenshots

OS details

Additional context

Describe the bug
ChainID is harcoded to 1 in build all construction -

To Reproduce

Expected behavior
It should be based on ETH RPC node

Screenshots

OS details

Additional context

Is your feature request related to a problem? Please describe.
Current chainio clients are overly complex and are pretty frustrating to work with (see for eg the chainio/constructor flow for constructing all clients).

Describe the solution you'd like
The current clients hierarchy looks like

but we'd rather it look like

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Update bindings according to PR
Layr-Labs/eigenlayer-contracts#562

TLDR: remove earningsReciever

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Right now we return a generic error message of invalid url but we want to be specific so it's east to debug
https://github.com/Layr-Labs/eigensdk-go/blob/master/types/operator_metadata.go#L69
https://github.com/Layr-Labs/eigensdk-go/blob/master/types/operator_metadata.go#L77

Describe the solution you'd like
Better return error

Describe alternatives you've considered

Additional context

Describe the bug

checkSignatures expects nonsigner operator pubkeys to be sorted, but the blsagg service currently doesn't sort operator pubkeys. See

To Reproduce
Don't have a reproducible test right now. This was raised by an avs team. Will need to add a test case for this.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Describe the bug
The links to contract client modules within the chainio/README.md documentation are incorrect or outdated, pointing to non-existent or incorrect paths.

To Reproduce

1. Navigate to chainio/README.md.
2. Click on the links directed towards the eigenlayer core contracts and avs registry contracts.
3. Observe that the links direct to ./elcontracts/ and ./avsregistry/, which do not accurately reflect the current project structure.

Expected behavior
The links should direct users to ./clients/elcontracts/ and ./clients/avsregistry/.

Additional context
The fix for this will be linked in a PR

Is your feature request related to a problem? Please describe.

Right now, for onchain transactions, we are using default smart contract bindings to send the transaction.
This has few limitation

• We can't adjust gas for transactions and this can lead to tx failures
• We don't have a good signing and nonce management logic

Describe the solution you'd like

We want to create an optimism like Transaction Manager for handling onchain transactions

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
Right now smart contract bindings have a lot of implementation bindings (and some interface bindings like ISlasher. Ideally we should only have Interfaces bindings so that we don't need to update bindings whenever contract implementation changes

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
Implement a tool which can create keys in batches for testing. Since this is for AVS testing, we are creating a utility in SDK.

Note: This utility should be only used for testing

Describe the solution you'd like
both for bls/ecdsa

• A private.keys.txt file with one private key hex in each line
• A folder which has all the encrypted json files
• A private.keys.loc.txt file with one filename for each private key
• A passwords.txt file with one password for each of those keys

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
The avs node spec requires avs node software to instrument all of its json-rpc calls. We implemented this in instrumented_client.go

This is useful but we feel like it might be even more useful to have instrumentation at the function call level. Currently all different contract calls/transactions to eigenlayer core and avs contracts only increase the eth_call metric, so we

Describe the solution you'd like
After we refactor the chainIO clients #26, we could create instrumented_contract_caller/transactor/filterer pretty easily following the same pattern, but these would instrument function calls and export prometheus metrics with call/tx counts + duration of each call to each function. We could then potentially also add those as eigen_ metrics... tbd.

Describe the bug
Sending multiple trx in quick succession ends up with one of them failing due to nonce too low.
Error handler outputs the error message with associated trx.Hash(), which fails with SIGSEGV.
Removing the hash from err message "fixed" the crash.

To Reproduce
Duplicate the line in code which sends a trx, ending up with two simultaneous trxs with one failing with 'nonce too low' and producing the crash

Expected behavior
Does not crash

OS details

• OS: Mac/m1

Additional context
Fixed on a fork by adding a mutex to allow only one in flight trx, and fetching a new nonce
master...mangata-finance:eigensdk-go:feature/expired-responses#diff-223616ebe949cff704b8d355a461951d12ccf06b07d593d9983879d1735bf140

We just open sourced the new eigenlayer-middleware repo, and moved the avs registry contracts there. They are still also in eigenlayer-contracts for now, but will be removed soon, so we should migrate asap.

We originally took much of the crypto/bls module from eigenDA, so it currently contains code for both bls and some incredible-squaring specific code.

We need to refactor it and take out all the incredible-squaring code and put that in its own repo.

Structured logs are nice for computer ingestion, but they are impossible to read when output to stdout.

bunyan for example has a cli tool that can be used to pipe structured json logs to and transforms them into colorized, idented logs that are nice to read. We should find a way to do this for our zapper logs slog logs.

Issue to track deliverables we want to ship for Q4

Is your feature request related to a problem? Please describe.
We need to refactor types and utils so that it's in some standard way and not create circular dependencies.

Describe the solution you'd like

• Yet to define

Describe alternatives you've considered

Additional context

Implementation started in branch samlaf/metrics

Action Items

• Comply with avs-spec prometheus metrics
• Comply with avs-spec node api

We want to add support for remote signers (unsure if they all support the eth_sign interface or not..) such as:

• Web3 signer
• fireblocks
• Cubist anti-slasher

To make this issue self-contained, and due to demand for this for hot wallets, we need to implement ASAP the interface for fireblocks.

Action Items

• implement remote signer support for signing from fireblocks

Describe the bug

Got the following log when attempting to register an operator:

2023-10-19T00:43:23.109Z        INFO    logging/zap_logger.go:89        registering operator 0xa306ac142eedc7bb636e6fd32d967e971ed986e3 to EigenLayer
2023/10/19 00:43:25 unsupported method: eth_maxPriorityFeePerGas

Seems to be an issue when RPC does not support eth_maxPriorityFeePerGas. Need a fallback mechanism, here is how EigenDA does it https://github.com/Layr-Labs/eigenda/blob/d4204a81e5bc98077d676fdce723f777e860f08e/common/geth/client.go#L108.

To Reproduce

Followed the registration flow and ran

eigenlayer operator register operator-config.yaml

Expected behavior

Should successfully register operator.

Screenshots

OS details

Additional context

Is your feature request related to a problem? Please describe.

The node spec currently requires eigen_registered_stakes to be exported. We have made this available in the economic collector which periodically calls the chain, but this limits its use. For eg, teams that don't use golang cannot use it.

Describe the solution you'd like

Exported metrics are self contained and should be packaged as a separate binary to be run as a sidecar. We should do this.

Eigenlayer is based on a pull model, so AVSs need to pull delegation manager shares to their AVS contracts periodically. We have explored different potential models in this internal document and decided to write a binary that can be run by AVS teams that calls stakeUpdate() on its registry contract once per day, for every operator.

Let's just write a simple binary without infra choices into consideration for now. We can base our implementation off of the avs-churner.

The functions in the signerv2 (for eg this) return bind.SignerFn instead of SignerFn, which is confusing because the txMgr needs a SignerFn. So the user either has to wrap the bind.SignerFn themselves, or use the more complicated (and also confusing) signerFromConfig. This one is confusing because forcing user to use the config which has too many fields and unclear which ones are mandatory and which ones are not.

I think we should just make the simple constructors return SignerFn directly, and then the SignerFromConfig can just call those and return directly, instead of wrapping their returned bind.SignerFn in a SignerFn.

Is your feature request related to a problem? Please describe.
Have Errors in errors.go file so they are easily identifiable and exportable and useable by client

Describe the solution you'd like

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

NewOperatorsInfoServiceInMemory takes too much time to initialize.

It could start scanning the blockchain from some arbitrary block. QueryExistingRegisteredOperatorPubKeys already provides that option.

Describe the bug
the installation commands in our documentation are inconsistently formatted with unintended leading spaces in front of some go install commands and egnkey and egnaddr. Just a small formatting discrepancy.

To Reproduce
Go to the egnaddrs and egnkey README.md file and look under the how to install

Expected behavior
No spaces after the go install and egnkey and egnaddr

Screenshots

Additional context
Will be linked to an PR where this is fixed soon.

Is your feature request related to a problem? Please describe.

We want to update the operator metadata validation - https://github.com/Layr-Labs/eigensdk-go/blob/master/types/operator_metadata.go#L38

Describe the solution you'd like

• Logo image should be a square
• Only support svg/png/jpg/webp
• 200 char on name

Describe alternatives you've considered

Additional context

Currently egnkey binary only allows me to generate a bunch of keys.
My use case is that I have my private key, which I can export from metamask in hex, and I want to be able to store it in a web3 secret storage file to comply with incredible-squaring operator requirements (see config file)

Is your feature request related to a problem? Please describe.

Right now the metrics interface and its implementation combine 2 separate concerns that should be separate:

• one struct to keep the prometheus variables and helper functions to change them
• actual metric server that listens on 9090

Problem comes when multiple services want to register their own metrics.
Each should have its own Metrics struct to keep track of its prom state and change them, but shouldn't also be a metrics server, because then its confusing where the separation of concern is.

Describe the solution you'd like

We should have a MetricsServer struct whose only purpose is to take in a registry (or many?) and that has a single StartServer() function to start its server.

Describe alternatives you've considered

Additional context

Describe the bug

Right now the validation of operator is not correct. According to EL contracts It can be set to 0x0

https://github.com/Layr-Labs/eigensdk-go/blob/master/types/operator.go#L39

To Reproduce

Expected behavior
Pass validation if user has 0x0 as DelegationApproverAddress

Screenshots

OS details

Additional context

Describe the bug

https://github.com/Layr-Labs/eigensdk-go/blob/master/services/bls_aggregation/blsagg_test.go

blsagg tests are flakey and fails randomly? Maybe race conditions?

For ex: this job is failing - https://github.com/Layr-Labs/eigensdk-go/actions/runs/6621863264/job/17986494970?pr=54

whereas the other job which also runs lets is passing - https://github.com/Layr-Labs/eigensdk-go/actions/runs/6621863263/job/17986494959?pr=54

To Reproduce

Expected behavior

Screenshots

OS details

Additional context

See https://go.dev/blog/examples

examples show up in godoc so will be very useful for helping avs teams understand our modules.

Would be nice to have a util binary to get all addresses, something like

$$$ eigenaddrs goerli/mainnet
slasher: <SLASHERADDR>
delegationManager: <DMADDR>
blsregistrycoordinator: <BLSREGISTRYCOORD_ADDR>

This would require hardcoding the goerli and mainnet addresses into the sdk. This should also have the following option

$$$ eigenaddrs --from-servicemanager <SERVICEMANAGER_ADDR>
slasher: <SLASHERADDR>
delegationManager: <DMADDR>
blsregistrycoordinator: <BLSREGISTRYCOORD_ADDR>
...

which would help avs developers check that their serviceManager points to all the correct contracts.

See this example. This test fails sometimes, but we just rerun it and it works fine. There's probably a race condition going on.
https://github.com/Layr-Labs/eigensdk-go/actions/runs/8809483189/job/24180357677?pr=214

Is your feature request related to a problem? Please describe.

• Currently WrapError function lives in types which doesn't seem right place
• Interface expects two errors which is not great since, a lot of places has a string input (and error inputs in some place)

Describe the solution you'd like

• Move WrapError to utils or similar
• Interface should accept any type and then based on type do the Wrapping.

Describe alternatives you've considered

Additional context

currently the clients.BuildAll() function returns high-level chainio clients.
Power users might want direct access to bindings + wallet/txmgr, so we should also make those available

Should prob also write improve the chainio README to show these 2 different ways of interacting with contracts (high-level and low-level).

Running this on master

go test ./... -race
...
==================
WARNING: DATA RACE
Write at 0x00c00007cde8 by goroutine 17:
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:147 +0x187
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Previous read at 0x00c00007cde8 by goroutine 18:
  math/big.(*Int).Mul()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:194 +0x1b5
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.checkIfStakeThresholdsMet()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:370 +0x1ab
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:268 +0x11de
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Goroutine 17 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:186 +0x805
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44

Goroutine 18 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:190 +0x8b4
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44
==================
==================
WARNING: DATA RACE
Write at 0x00c00007cde0 by goroutine 17:
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:158 +0x4ed
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Previous read at 0x00c00007cde0 by goroutine 18:
  math/big.(*Int).Mul()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:195 +0x2b4
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.checkIfStakeThresholdsMet()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:370 +0x1ab
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:268 +0x11de
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Goroutine 17 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:186 +0x805
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44

Goroutine 18 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:190 +0x8b4
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44
==================
==================
WARNING: DATA RACE
Read at 0x00c00007cdc0 by goroutine 18:
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:143 +0x4d
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Previous write at 0x00c00007cdc0 by goroutine 17:
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:158 +0x4ed
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Goroutine 18 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:190 +0x8b4
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44

Goroutine 17 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:186 +0x805
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44
==================
==================
WARNING: DATA RACE
Read at 0x00c00007cdc8 by goroutine 18:
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:147 +0xb7
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Previous write at 0x00c00007cdc8 by goroutine 17:
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:147 +0x187
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Goroutine 18 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:190 +0x8b4
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44

Goroutine 17 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:186 +0x805
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44
==================
==================
WARNING: DATA RACE
Write at 0x00c00002f2c8 by goroutine 18:
  math/big.nat.add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/nat.go:123 +0x264
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:147 +0x168
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Previous write at 0x00c00002f2c8 by goroutine 17:
  math/big.nat.add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/nat.go:123 +0x264
  math/big.(*Int).Add()
      /usr/local/Cellar/go/1.21.4/libexec/src/math/big/int.go:147 +0x168
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).singleTaskAggregatorGoroutineFunc()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:261 +0x1c44
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask.func1()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0xf3

Goroutine 18 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:190 +0x8b4
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44

Goroutine 17 (running) created at:
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.(*BlsAggregatorService).InitializeNewTask()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg.go:161 +0x2e6
  github.com/Layr-Labs/eigensdk-go/services/bls_aggregation.TestBlsAgg.func4()
      /Users/estensen/Developer/eigensdk-go/services/bls_aggregation/blsagg_test.go:186 +0x805
  testing.tRunner()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0x238
  testing.(*T).Run.func1()
      /usr/local/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x44
==================
--- FAIL: TestBlsAgg (5.06s)
    --- FAIL: TestBlsAgg/2_concurrent_tasks_2_quorums_2_operators_2_correct_signatures (0.02s)
        testing.go:1465: race detected during execution of test
    testing.go:1465: race detected during execution of test
FAIL
FAIL	github.com/Layr-Labs/eigensdk-go/services/bls_aggregation	7.036s
ok  	github.com/Layr-Labs/eigensdk-go/services/pubkeycompendium	1.877s
ok  	github.com/Layr-Labs/eigensdk-go/signer	17.653s
ok  	github.com/Layr-Labs/eigensdk-go/types	1.598s
FAIL

Describe the bug

Right now Dependabot doesn't push the coverage to wiki due to some permission issues. We can't merge PR like this now - #17

To Reproduce

Expected behavior
Dependabot should be able to push or we remove the coverage check from PRs?

Screenshots

OS details

Additional context

Spec has been updated with new resource endpoints: https://eigen.nethermind.io/docs/spec/api/

Our node api implementation still has the old endpoints. Need to update.

EDIT: this is actually really only the https://eigen.nethermind.io/docs/spec/api/#get-eigennode endpoint

We use services to read state and events from eigenlayer and avs contracts. We currently only have implementations (eg1, eg2) that read state using eth_ calls and events using websocket subscriptions.

We should write an implementation that is backed by an indexer instead of an eth client.

Action Items

• write a blspubkeycompendiumservice implementation that uses thegraph as backend
• write an avsregistryservice implementation that uses thegraph as backend

Describe the bug
The economic collector currently fetches the operatorId dynamically. However, it happily returns operatorId of 0 if that is what it gets. It should instead print a warning that operatorId is 0 (aka operator has not registered) and skip the metric collection, since currently it doesnt, which results in unrelated errors:

ERROR[11-02|00:39:54.339] Failed to get operators state            err="execution reverted" caller=reader.go:94
ERROR[11-02|00:39:54.339] Failed to get operator stake             err="execution reverted" caller=economic.go:140