ADR 001: Umee Module #1
Conversation
|
/cc @fedekunze |
There was a problem hiding this comment.
The ADR looks good. My main comments are around two areas:
-
ability to withdraw and re-delegate staking rewards. One suggestion was to do this after a certain amount of epochs eg. withdraw and re-delegate staking rewards every 30-50 Epochs. My understanding is that the UX of this would be a bit clumsy, though it would be very worth it for meToken users to be able to have some form of compounded proof of stake yield to better reflect real world continuous compounding.
-
It would make sense for the meToken to mirror/mimic the inflation that is happening with the staked Atoms. eg. as staked Atoms are receiving staking rewards, the meToken uses some sort of oracle to also reflect the inflation of the staking rewards.
The ADR in its current state already looks solid. These two points I mentioned could be visited in the future, though I just wanted to voice them to make sure that we take them into consideration.
| - Track the sender and amount in the module's state. | ||
| - Mint derivative meTokens and send them to the source sender's Umee account. | ||
|
|
||
| At the beginning of a staking epoch, E<sub>1</sub> in `BeginBlock`, the `x/umee` |
There was a problem hiding this comment.
what's the proposed (default) epoch value in blocks?
There was a problem hiding this comment.
No clue. Suggestions? I'm thinking a few hours.
There was a problem hiding this comment.
Are there any examples of other networks that are staking in epochs? If not, would we be setting some sort of standard approach?
There was a problem hiding this comment.
What are the pros and cons of having an epoch vs not having an epoch for pending delegations?
Why not just delegate immediately? Is this to synchronize on governance decisions?
If governance decisions don't change, it seems like you could delegate as soon as the next block?
There was a problem hiding this comment.
@brentxu There is no current SDK-based chain that uses epochs, but many plan to such as the Hub and Osmosis. I believe both will have epoch on the order of a few hours.
@khoslaventures An epoch is required, you cannot do this without an epoch because without an epoch, the validator set can change at any block making it practically impossible to do the cross-chain delegation(s). In other words, it's mandatory, even we interchain accounts finally land, I still believe epochs will be required.
|
|
||
| ### Negative | ||
|
|
||
| - Requires the maintenance of a validator controlled multisig account each epoch. |
There was a problem hiding this comment.
I assume this requires the a hot key too
There was a problem hiding this comment.
Yes, but there is no other choice AFAIK :-/
There was a problem hiding this comment.
yeah, I guess we will have to write that down too
There was a problem hiding this comment.
If the multisig is weighted according to stake on Umee then essentially consensus security must be broken in order to compromise the multisig?
Reinforcements may be done since there's a chance that KMS cloud services will get FIPs 140-3 compliant and have ed25519 hardware signers in the cloud soon this year.
Wondering if it's possible to have a security model to prevent functionality other than delegations related transactions on the multisig and returning owed money to the user. Sort of like how proxy contracts work on Ethereum.
There was a problem hiding this comment.
The multisig is not weighted -- it's a simple n/n multisig. All validators are required to sign per epoch.
There was a problem hiding this comment.
So let's say we go with the n/n approach - managing this multisig is still quite difficult across chains if you want validator set flexibility? Also with n of n you'd have to be stricter about who can become a validator because misoperations from anyone is opportunity cost and would stop progress.
It also seems dangerous, what happens if you have an n of n multisig and someone's key set up is destroyed? All the user funds are gone then because of one validator?
There was a problem hiding this comment.
managing this multisig is still quite difficult across chains if you want validator set flexibility?
What is being managed cross chain? There is a single validator set multisig per epoch which must exist on the native ATOM chain. Validator sets can change every epoch.
Also with n of n you'd have to be stricter about who can become a validator because misoperations from anyone is opportunity cost and would stop progress.
Yes, if a single validator misses a tx, the delegation does not happen for that epoch. The chain progress normally though.
It also seems dangerous, what happens if you have an n of n multisig and someone's key set up is destroyed? All the user funds are gone then because of one validator?
I think we'd have the validators submit txs first, and then send funds to that account on the native ATOM chain once we received all signatures. Only then do we emit the event.
I get this process is not clean, but I cannot think of any other way to do cross-chain delegation. Do you have alternative ideas?
There was a problem hiding this comment.
What is being managed cross chain? There is a single validator set multisig per epoch which must exist on the native ATOM chain. Validator sets can change every epoch.
Let me rephrase, I may have misunderstood - so there's epoch management on the Umee chain and a multisig that's managed on the ATOM chain by the Umee validators, which gets managed by the x/umee module if I understand correctly. If we have epochs, then validator set changes are easy. I am not sure how the multisig gets updated though through these epochs for staked assets, but the notion of an epoch is useful for synchronizing events to happen.
I think we'd have the validators submit txs first, and then send funds to that account on the native ATOM chain once we received all signatures. Only then do we emit the event.
That makes sense. I think this fact is still scary:
It also seems dangerous, what happens if you have an n of n multisig and someone's key set up is destroyed? All the user funds are gone then because of one validator?
Are weighted multisigs completely off the table? We'd have to add support to the SDK and Hub. Hopefully other chains would do it too.
| - Automatically send source ATOM tokens to the dedicated `ModuleAccount` pool | ||
| address instead of a user supplied address. | ||
| - Mark the transfer's amount in a pending queue, `PendingDelegationQueue`, to be | ||
| later used for delegation on the source chain. |
There was a problem hiding this comment.
do we only support the cosmos hub? what happens if an external chain, say Iris, also connects (independently) to Umee and performs a transfer? I guess the chains supported by Umee will have to be registered in the parameters, to prevent outgoing transfers to chains that don't have a validator multisig. Also, we need to take into consideration the naming collision for the chain ID in this case
There was a problem hiding this comment.
I guess we would also need to have a pending delegation queue by base denom type (ATOM, etc)
There was a problem hiding this comment.
We will only support the Hub (for now). Multi-chain becomes much more complex. As long as the tokens are ATOMs, it should work. Does this make sense?
There was a problem hiding this comment.
Makes sense, the only thing is that you somehow have to prevent other chains from doing the same (i.e only allow IBC connections with the umee module from the Hub)
| address instead of a user supplied address. | ||
| - Mark the transfer's amount in a pending queue, `PendingDelegationQueue`, to be | ||
| later used for delegation on the source chain. | ||
| - Track the sender and amount in the module's state. |
There was a problem hiding this comment.
see note about delegation validator address
| The validators in the current staking epoch, E<sub>1</sub>, will then construct, | ||
| sign, and broadcast multisig transactions to the Umee network. Once enough | ||
| transactions are received by the `x/umee` module, specifically 2/3 of total | ||
| staking weight, the `x/umee` module will store the constructed multisig transaction |
There was a problem hiding this comment.
staking weight of the validators signers of the multisig? or the total power? Can a validator not be part of the multisig? Can you opt-in or opt-out?
There was a problem hiding this comment.
Staking weight of the validators in the validator set, i.e. of total power. All validators have to be in the multisig per epoch. You cannot opt out.
There was a problem hiding this comment.
ack, it would be good to write that in the ADR
There was a problem hiding this comment.
So when the validator joins, the multisig weights will have to be updated with a weighted multisig design. This seems really hard to do given that there are multisigs on every chain Umee supports.
It would be interesting to have a design that allows you to put a weighted multisig on Umee, but then proxies everything to other accounts on other chains. The concept would be:
- On Umee, I have a weighted multisig
- On Cosmos, I have an account that when it receives a threshold signature from the weighted multisig originated from Umee chain, it performs the action I want (i.e. Delegation)
There was a problem hiding this comment.
There are no weights. If the account already exists on the native ATOM chain, great, we do nothing. If it does not exist, it'll have to be created first, where the Umee network will send a tx to the native ATOM chain to create the account (by sending some funds to it). The multi-sig is not weighted, it's a simple n/n setup where all validators are required to sign.
There was a problem hiding this comment.
It seems like having a weighted multisig would be worth it and the sdk would have to be extended to support it - otherwise it would limit who can become a validator on the network
There was a problem hiding this comment.
There is no limit to who can become a validator on Umee, but having power-based multi-sig would be nice.
|
|
||
| - Allows for cross-chain delegations in a decentralized manner. | ||
|
|
||
| ### Negative |
There was a problem hiding this comment.
I assume that the validator set can't be that large because of the multisig?
There was a problem hiding this comment.
what do you think the limitations in size would be? could it feasibly expand in the future?
There was a problem hiding this comment.
Cosmos does not make use of cryptographic threshold signatures. This means for every m-of-n multisig there is m signatures. This would likely result in some big performance implications for consensus but ultimately it depends how often we are updating the delegation allocations of the multisig as well.
Here is a reference implementation for cryptographic threshold ed25519
This is where I am assuming the issues would be. Gathering all these signatures and validating would be fine otherwise.
There was a problem hiding this comment.
Yes, the SDK would need to support this in order for us to use threshold signatures.
|
|
||
| ## Context | ||
|
|
||
| Umee is a Universal Capital Facility that can collateralize assets on one |
There was a problem hiding this comment.
I wonder if people would be more familiar with the term money market. Cross chain money market?
Anyhow it's an ADR so more relevant to the general messaging.
There was a problem hiding this comment.
That's a question for @brentxu :) (I took this from the paper)
There was a problem hiding this comment.
Yes - it is pretty similar to cross chain money markets. Though there are aspects of this protocol that are beyond money markets eg an ecosystem where different blockchains can interact with cross chain leverage. A capital facility is like a borrowing facility used by central banks for extending credit. Umee is a blockchain hub that can also extend leverage. I'm open to figuring out the general messaging. Thanks for pointing this out @khoslaventures
| For the initial MVP implementation of the Umee network, we require the ability | ||
| for users to be able to send ATOM tokens to a dedicated pool in the Umee network | ||
| via IBC. ATOM tokens deposited into the Umee pool will mint a derivative meToken | ||
| in a one-to-one ratio, i.e. one ATOM mints one meToken derivative. |
There was a problem hiding this comment.
You can mention it's meATOM here since ATOM is the only example here.
There was a problem hiding this comment.
Yeh thanks for pointing this out - we'll want to properly document naming conventions - pretty important for defi protocols considering all of the stuff that is moving around.
| - Track the sender and amount in the module's state. | ||
| - Mint derivative meTokens and send them to the source sender's Umee account. | ||
|
|
||
| At the beginning of a staking epoch, E<sub>1</sub> in `BeginBlock`, the `x/umee` |
There was a problem hiding this comment.
What are the pros and cons of having an epoch vs not having an epoch for pending delegations?
Why not just delegate immediately? Is this to synchronize on governance decisions?
If governance decisions don't change, it seems like you could delegate as soon as the next block?
| The validators in the current staking epoch, E<sub>1</sub>, will then construct, | ||
| sign, and broadcast multisig transactions to the Umee network. Once enough | ||
| transactions are received by the `x/umee` module, specifically 2/3 of total | ||
| staking weight, the `x/umee` module will store the constructed multisig transaction |
There was a problem hiding this comment.
So when the validator joins, the multisig weights will have to be updated with a weighted multisig design. This seems really hard to do given that there are multisigs on every chain Umee supports.
It would be interesting to have a design that allows you to put a weighted multisig on Umee, but then proxies everything to other accounts on other chains. The concept would be:
- On Umee, I have a weighted multisig
- On Cosmos, I have an account that when it receives a threshold signature from the weighted multisig originated from Umee chain, it performs the action I want (i.e. Delegation)
|
|
||
| ### Negative | ||
|
|
||
| - Requires the maintenance of a validator controlled multisig account each epoch. |
There was a problem hiding this comment.
If the multisig is weighted according to stake on Umee then essentially consensus security must be broken in order to compromise the multisig?
Reinforcements may be done since there's a chance that KMS cloud services will get FIPs 140-3 compliant and have ed25519 hardware signers in the cloud soon this year.
Wondering if it's possible to have a security model to prevent functionality other than delegations related transactions on the multisig and returning owed money to the user. Sort of like how proxy contracts work on Ethereum.
| cross-chain delegations on the destination ATOM chain. During each `EndBlock` | ||
| execution in the `x/umee` module, we will construct a series of messages that will | ||
| be executed on the source ATOM chain via `TryRunTx` as defined by the | ||
| `Interchain Account` ICS standard. Finally, the `PendingDelegationQueue` will be |
There was a problem hiding this comment.
I read through the interchain account standard and I didn't really see any mention of signers...
all I see is a confusing paragraph on it from the spec
It does not restrict how you can distinguish signers that was not made by the counterparty chain. But the most common way would be to record the account in state when the interchain account is registered and to verify that signers are recorded interchain account.
So does this mean that we still need to implement something that's effectively a weighted multisig? Is that what ModuleAccount is?
There was a problem hiding this comment.
Good question. No, there no need for any multi-sig. It's completely unnecessary. Validators are not responsible for signing anything in this context. Keep in mind, the multi-sig approach was always a temporary stop-gap approach until Interchain accounts became available.
Interchain accounts take care of authorization and authentication of cross-chain accounts and the messages they can execute. They do this through the Interchain account module, leveraging IBC's ports and channels.
That being said, a relayer is still responsible for signing and relaying the actual transactions. This is no different than any other IBC-type transaction.
👉 RENDERED 👈