Replies: 10 comments 10 replies
-
I came by this in the Celestia documentation and don't see a reason not to do the same thing (go from
We should ONLY support one or the other, not both. Leaning heavily towards |
Beta Was this translation helpful? Give feedback.
-
@Olshansk Following an offline chat with @noot
This can be achieved through the use of their library [1] which can produce a proof that two public keys (on two different curves) came from the same private key - essentially a private key from Morse can be used to create a new
So maybe a better approach would be some sort of bridge similar to wPOKT, that incorporates this or simply allows the user to choose the receiving address. |
Beta Was this translation helpful? Give feedback.
-
Discussed offline but mentioning here: |
Beta Was this translation helpful? Give feedback.
-
I've spoke to the team at Binary Builders (maintaining CometBFT) who are helping another team to migrate as well. Just starting a thread here to follow up in the future. |
Beta Was this translation helpful? Give feedback.
-
Open ended idea. Is this possible?
|
Beta Was this translation helpful? Give feedback.
-
An idea from @cleanunicorn is to:
The curious reader can likely see a lot of edge cases and open-ended problems that I'm explicitly not enumerating here. However, if you have answers to these in-between-the-line problems, please share your solutions! |
Beta Was this translation helpful? Give feedback.
-
I believe we have to build a simple bridge that will allow burning Morse tokens into Shannon ones. Keep in mind there are big exchange wallets, which are likely secured by HSM (no access to pk material). The question is how we "burn" staked nodes / apps? I assume we want to avoid scenario when node needs to be unstaked, tokens burned and staked again. Can we patch Morse to allow such burning mechanism? |
Beta Was this translation helpful? Give feedback.
-
In case of capturing Morse snapshot and generating genesis.json for Shannon I think we can handle claims on Shannon. We can create simple ed25519 challenge, so only the user who owns the Morse wallet can provide valid signature. That way, Shannon can support simple call If the signature is valid you can be certain that the owner of Morse wallet wants to move tokens to specific shannon address and you can update the state. Or am I wrong here? |
Beta Was this translation helpful? Give feedback.
-
As Essentially generating the proof would look like: import (
"github.com/athanorlabs/go-dleq"
"github.com/athanorlabs/go-dleq/ed25519"
"github.com/athanorlabs/go-dleq/secp256k1"
)
curveA := secp256k1.NewCurve()
curveB := ed25519.NewCurve()
x := [32]byte{}
copy(x[:], privateKey) // 256-bits = 32 bytes so we copy in the raw private key
if err != nil {
panic(err)
}
proof, err := dleq.NewProof(curveA, curveB, x)
if err != nil {
panic(err)
}
err = proof.Verify(curveA, curveB)
if err != nil {
panic(err)
} We could then use the proof to let people using testnet create their accounts, generate a proof and then use these once verified on Morse to generate a new genesis file. |
Beta Was this translation helpful? Give feedback.
-
Posting a thread I have had with Alin (from aptos) for a cryptographic solution but don't think its possible: https://x.com/alinush407/status/1800750678668870115 |
Beta Was this translation helpful? Give feedback.
-
Overview
Currently
poktroll
supportssecp256k1
keys (as this seems to be the cosmos standard). However cosmos also has aed25519
key package that implements all the same interfaces thesecp256k1
keys use. This in theory allows them to be used interchangeably.Summary
v0
/Morse
usesed25519
keys. There are numerous benefits to usinged25519
keys (in terms of signature verification cost). However the main topic of discussion here is related to the migration of state fromv0
/Morse
intov1
/Shannon
.If we were to attempt to port over account balances as is this would be impossible. Nobody would be able to access their funds as they don't hold the corresponding
secp256k1
private key to use the funds associated with their address.Solutions
There are numerous potential solutions to this problem:
wPOKT
works that enables people to bridge over their balances to a newsecp256k1
keyed25519
keys andsecp256k1
keys and port over state directly. If users want to use asecp256k1
key for any reasons they can they just setup a new account and transfer their funds accrossSupport
The
cosmos-sdk
keyring implemented by the 99designs/keyring package. The keyring documentation states they support bothsecp256k1
anded25519
keys [1]. And the cosmos-sdk has both thesecp256k1
anded25519
implementations as mentioned earlier in their cryptokeys package [2][1] https://docs.cosmos.network/v0.46/basics/accounts.html#keyring
[2] https://github.com/cosmos/cosmos-sdk/tree/main/crypto/keys
Open Questions
Firstly the main area where this change would affect the current codebase is in the new
pkg/crypto/rings
RingCache interface. However the ring library we use again supports both thesecp256k1
anded25519
curves [3][4][5].We will be able to easily derive the correct points on these curves to build a ring using one or the other curve, however it would require putting in another PR to [3] that would enable the creation of a ring using different curve types (this may be rather complex)
Finally the last remaining question is how would one be able to decide which key type they want to create when making a new account with
poktrolld
this may already exist but would need to be discovered and documented.[3] https://github.com/noot/ring-go
[4] https://github.com/AthanorLabs/go-dleq/blob/master/secp256k1/curve.go
[5] https://github.com/AthanorLabs/go-dleq/blob/master/ed25519/curve.go
Next Steps
poktrolld
binaryBeta Was this translation helpful? Give feedback.
All reactions