[restaking PoC] retrieve avs operators state #341
Conversation
| license = "MIT OR Apache-2.0" | ||
|
|
||
| [dependencies] | ||
| alloy = { version = "0.9.2", features = ["full"] } |
There was a problem hiding this comment.
Wondering if using alloy intead of ethers is a good choice, I have not found satisfying resources to mock Contracts / Provider.
There was a problem hiding this comment.
I've heard alloy is now the preferred library for folks. Curious if either let's you use a16z's helios (https://github.com/a16z/helios) to verify results or if they assume you trust your RPC.
There was a problem hiding this comment.
Yep this is why I did not use ethers, it is now deprecated 👍
I don’t see a reason it would not let you interact with Elios, but I might be missing something🤔
There was a problem hiding this comment.
Concerning the testing, I think about deploying a Mocked Contract on Anvil, returning an harcoded value. It looks lile the easiest way to have tests for this poc
There was a problem hiding this comment.
That makes sense for me (and aligns with my understanding of how to best test).
Its a shame the testing has to be so heavyweight for this but I think that's the best way to ensure it works reliably (unless they change the contract upstream I suppose....unless it is immutable?).
There was a problem hiding this comment.
Its a shame the testing has to be so heavyweight for this but I think that's the best way to ensure it works reliably (unless they change the contract upstream I suppose....unless it is immutable?).
Yep it is a little bit heavy 😀 but when your build process is ready to compile Solidity Mocked Contract, everything is almost done.
Technically contracts could evolve, teams developing their AVS are responsible to deploy middleware contracts, these could be different in few months.
There was a problem hiding this comment.
I have added basic tests in the new commits. I think tomorrow I will look into Symbiotic in details.
Note that operator has a specific weights for each quorum it is part of. I need to take another look but AVS team can apply like a "coefficient" on some quorum. Hence to retrieve a global Weight this would require to get these coefficients (maybe it's out of the scope right now)
There was a problem hiding this comment.
If you want to spike on a separate version of this PR that just includes Symbiotic stuff, may make it easier to understand how the interface could be unified (if we determine that even makes sense).
We may just opt to have 2 dialects with different interfaces entirely (like restaking::eigen and restaking::symbiotic)
There was a problem hiding this comment.
It might make sense, it does not bother you if I open a second Draft to show the Symbiotic stuff?
We may just opt to have 2 dialects with different interfaces entirely (like restaking::eigen and restaking::symbiotic)
Yep, and even if at the beginning they are distinct, at a moment a common way to use it could appear, but it will potentially be iterative 🙂
| let mut operator_staked: Option<U256> = None; | ||
| let mut total_staked: U256 = Uint::from(0); | ||
| for operator in quorum_operators { | ||
| let stake = operator.stake; |
There was a problem hiding this comment.
After some verifications, the stake obtained from the call is the weight of the operator in this quorum 👍
| ); | ||
|
|
||
| let builder = registry_coordinator.quorumCount(); | ||
| let quorum_count = builder.call().await?._0; |
There was a problem hiding this comment.
get the current quorum count. In my opinion, we don't care if some quorums did not exist at blockNumber we fetch data from.
There was a problem hiding this comment.
quorumCount means you're selecting the quorum that was last created, we need to allow configuration at the operator set level for the AVS, as different quorums may be performing different tasks on different quorums
There was a problem hiding this comment.
Yes, the PR gets the current quorumCount (N), then it asks for state for quorums from 1 to N
There was a problem hiding this comment.
I think there's a design choice here whether we should allow to configure commonware at the operator set / quorum (quorum will be renamed to operator set eventually) or expose this to commoneware to plug in with other modules
There was a problem hiding this comment.
You mean the interest of commonware could be eventually restricted to a specific subset of OperationSet/Quorum instead of All ?
There was a problem hiding this comment.
It's an open question, I think that for starters assuming this is a dedicated commonware env for one operator set will be easier and more useful to support as that is the case for most AVS usecases
Will send this to people in eigenlayer for their opinion
There was a problem hiding this comment.
where is this method used? not following the intention here
There was a problem hiding this comment.
Right here:
monorepo/restaking/src/eigenlayer/mod.rs
Line 176 in f98d25c
There was a problem hiding this comment.
the operator state retriever gives us the current operator list, but in order to get the sockets and bls pubkeys we need to add the interfaces for the blsapk library and the socket registry
This will give us the g1 and socket. If we need the g2 as well then we can get it like as referenced here
There was a problem hiding this comment.
Thanks for the additional informations. If we want to get all of these informations from a single request, we need a "local" Solidity contract returning the operator data ( like OperatorStateRetriever) + sockets & bls pubkeys.
There was a problem hiding this comment.
on the other hand, I don't think it is useful to have bls pubkeys in the same request as it never changes.
No description provided.