Morse -> Shannon Key Support & Migration

[h5law]

Overview

Currently poktroll supports secp256k1 keys (as this seems to be the cosmos standard). However cosmos also has a ed25519 key package that implements all the same interfaces the secp256k1 keys use. This in theory allows them to be used interchangeably.

Summary

v0/Morse uses ed25519 keys. There are numerous benefits to using ed25519 keys (in terms of signature verification cost). However the main topic of discussion here is related to the migration of state from v0/Morse into v1/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:

1. Have a bridge similar to how wPOKT works that enables people to bridge over their balances to a new secp256k1 key
2. Implement support for both ed25519 keys and secp256k1 keys and port over state directly. If users want to use a secp256k1 key for any reasons they can they just setup a new account and transfer their funds accross

Support

The cosmos-sdk keyring implemented by the 99designs/keyring package. The keyring documentation states they support both secp256k1 and ed25519 keys [1]. And the cosmos-sdk has both the secp256k1 and ed25519 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 the secp256k1 and ed25519 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

1. Decide whether we want to use both, one or the other and document why with detailed reasoning with analysis on the positives and negatives of each approach
2. Research and document how one could create a key with a specified type using the poktrolld binary
3. Implement ring creation for keys from different curves (non-trivial)
4. Implement switch logic during ring creation that determines the key type for point conversion (trivial)

[Olshansk]

1. Decide whether we want to use both, one or the other and document why with detailed reasoning with analysis on the positives and negatives of each approach

I came by this in the Celestia documentation and don't see a reason not to do the same thing (go from ed25519 to secp256k1) if possible.

Use the standard digital keys schemes provided by the Cosmos-SDK and Tendermint,
those being secp256k1 for user transactions, and tm-ed25519 for signing and verifying consensus messages.

3. Implement ring creation for keys from different curves (non-trivial)

We should ONLY support one or the other, not both. Leaning heavily towards secp256k1.

[h5law]

@Olshansk Following an offline chat with @noot

off the top of my head one solution could be to use a cross-curve discrete log equality proof, which proves that a public key on two different curves have the same private key, so you could prove that a user's ed25519 account has the same private key as their secp256k1 account

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 secp256k1 key-pair on the Shannon protocol and a proof can be generated to prove the key holder has the private key for both public keys. However,

the only drawback is that the proofs are sort of large like 50-60kb per proof i think

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.

[1] https://github.com/AthanorLabs/go-dleq

[Olshansk]

Do you know if the following is possible:
f(ed25519PrivKey) -> secp256k1PrivKey
f(Address(ed25519PubKey)) -> secp256k1Address

If it is, then we wouldn't even need to store the proofs!

[h5law]

priv key can be the same for both keys so f(ed25519PrivKey) -> secp256k1PrivKey possible but not address to address. The proof is what shows the two addresses (pubkeys) are from the same private key on different curves. A private key is just a []byte essentially

[h5law]

Will need to dive in more

[h5law]

Discussed offline but mentioning here: ed25519 keys are only for CometBFT validators - as such Morse using them was an error. They are not supported by the SDK for usage outside of this one purpose AFAIK. So a bridge seems to be the only option.

[Olshansk]

Providing additional historical context for when we pick this up:

• We forked Tendermint in Morse (it was an early decision in 2020 due to various factors)
• Morse / v0 (pocket-core) is a standalone L1 w/ multisig EVM bridge
• Shannon / v1 (poktroll) is a cosmos SDK compliant rollup built using https://rollkit.dev/ and leverage secp256k1 for accounts

[Olshansk]

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.

[Olshansk]

Open ended idea. Is this possible?

• Create a function Foo that uses PrivKey_ed25519 as a seed to generate PrivKey_secp256k1
• While also having a function Bar that uses PubKey_ed25519 as a seed to generate PubKey_secp256k1

Foo(PrivKey_ed25519) -> PrivKey_secp256k1
Bar(PubKey_ed25519) -> PubKey_secp256k1

[studna]

The first line seems like popular account abstraction, where you can make deterministic signature and use it to derive private key that's using different curve.

The second line does not seem to possible as you can only derive public key from corresponding private key (AFAIK).

[Olshansk]

An idea from @cleanunicorn is to:

1. While Morse is live (using ed25519), introduce a new consensus-breaking chain that gets release.
2. Use on-chain activity for active nodes to sign secp256k1 public keys and store them on-chain
3. Use (2) to generate a new genesis.json for Shannon

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!

[studna]

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?

[Olshansk]

Great questions. I don't have all the answers yet. A bridge is not off-the-table, but I'd ask / urge you to think about:

1. A solution w/o a bridge.
2. A solution that involves less moving pieces.

I plan to put together a design doc (1-3 pager) for ☝️ myself in ~2 months if no one comes up with one first.

[studna]

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 claim_old_balance(ed25519_public_key, shannon_address, ed25519_signature) where ed25519_signature=ed25519_sign(morse_address,balance,shannon_address) which you can reconstruct and verify inside claim_old_balance.

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?

[h5law]

As ed25519 keys and secp256k1 private keys are both 256-bits you can essentially use the same private key you use one Morse on Shannon - but you will have different public keys. What we can do however is create a proof stating the two public keys share the same private key using a cross-curve discrete logarithm proof. A go implementation can be found here.

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.

CC: @Olshansk @studna

[studna]

I don't think you can use same pk material for ed25519 and secp256k1 as they are different curves.

However, the proofs idea is similar to the one I mentioned #215 (comment).

Note that we should avoid any solution that requires access to raw private key.

[h5law]

AFAIK in elliptic curve cryptography a private key is a randomly selected integer and the public key is derived from this as a point on the curve so the same private key could be used for two curves but the derivation of the public key would be different and thus create different public keys.

But yeah exposing raw private keys is a bad idea but exposing the proofs wouldn't expose the key to my knowledge.

[studna]

@h5law You are correct. I see I misunderstood your idea of the proof that expects user will create their new secp256k1 wallet by using the same key pair. There are few problems with that still:

1. it requires user interaction and we should avoid this, because people might miss the window to take an action
2. it requires access to raw private key and we certainly should avoid this, because large POKT wallets are most likely secured by HSM

The easiest solution is imo the one I mentioned in the comment I referred. We can import Morse snapshot as genesis state for Shannon. I'll maybe elaborate.

Let's assume we want to migrate a wallet a8fd555cac0a3e17e089faff7a11219bae345646 from Morse to Shannon. The JSON state for this node could be:

// we need to move 4.99 POKT balance to Shannon
{"a8fd555cac0a3e17e089faff7a11219bae345646":4990000}

in this case, we would be moving around ~60000 wallets, roughly 3 MB state. But we can also move whole staked node to Shannon:

// we want to move staked node to Shannon
{
  "address": "a8fd555cac0a3e17e089faff7a11219bae345646",
  "balance": 4990000,
  "node": { "stake": 15100000000, ...anyMorseRequiredFields }
}

To reduce genesis state size, we can use sha compression, so the Morse state can look like:

[
  // each line represents compressed Morse wallet state (can include app/node details and other fields), 
  // which can be claimed on Shannon
  sha256(payload),
  // ...
]

That way we can compress any data structure into 32 bytes of information (per wallet). Here's how users will be able to "claim" their Morse wallet.

type MorsePayload struct {
	Balance int64
	// ...other data we want to unwrap on Shannon
}

type Payload struct {
	ShannonAddress string
	MorsePayload   MorsePayload
}

// callable state mutation
func ClaimMorse(ed25519PublicKey string, signedPayload Payload, ed25519Signature string) {
        // begin tx
	// Verify the payload was signed by the provided public key
	// @notice user cannot claim address he did not own, because the signature would not match
	err := VerifySignature(signedPayload, ed25519PublicKey, ed25519Signature)
	if err != nil {
		fmt.Println("Signature verification failed:", err)
		return
	}

	// Derive Morse address from provided public key
	address := fmt.Sprintf("%x", sha256.Sum256([]byte(ed25519PublicKey))[:40])

	// Reconstruct the state based on the user input and derived address
	// @notice MorsePayload can be provided from Morse -> Shannon Bridge UI, 
	// which will have access to Morse state at specific block that will be used for genesis generation
        // we can also archive uncompressed Morse State to S3 in the format we expect in this function
        // so users will still have a way to migrate to Shannon, even if they decide to do it 1 year from now
	morseState := map[string]interface{}{
		"address":       address,
		"balance":       signedPayload.MorsePayload.Balance,
		// Add other fields from MorsePayload as needed
	}

        // check if state can be claimed by new address (eg some conflicts?)
        CanClaimMorseState(morseState, signedPayload.ShannonAddress)

	// Compress the state using sha256 
	morseStateSha := sha256.Sum256([]byte(fmt.Sprintf("%v", morseState)))

	// Try to claim the hash from imported genesis state
	ClaimMorseState(morseStateSha)

	// At this point, we can be 100% sure that
	// owner of the Morse address initiated this action
	// and wants to "unwrap" his Morse state to a specific Shannon address
	UnwrapState(morseState, signedPayload.ShannonAddress)

        // end of tx, update state
}

The solution I am proposing:

• does not require direct access to the private key (friendly to CEXs, HW wallets and other HSMs)
• does not force user to take any actions pre-shannon, but also it can be fully e2e tested by mocking the signature verification and claiming state of every wallet, so we can prevent any issues with claims
• allows migration of nodes / apps and various state structures while allocating only 32B per address

[Olshansk]

tl;dr Sgtm. Not too worried about the implementation or state size, but the operational overhead is the real concern.

Things I'm not worried about:

• StateSize - It's a cool optimization, but given that every block is 16MB, I'd personally bias towards a simple (more explicit, human-readable, etc) 3MB genesis file keep things simpler.
• ClaimMorse - The business logic is relatively straightforward and lgtm.

Things I am worried about are:

• Overhead - communication, operation, support and tooling with all of the stake holder below.
• Node Runners & Gateways - Everyone has their own automation infra and will have a lot of work to migrate.
• Exchanges - Every exchange has its own infra and will need support. We see this even with just a node running.
• Individuals - Will likely have a website, tool/script or other.

Whether we built a website for one-off migrations, a tool for bulk migrations, provide hand-support for multiple individuals, it's a non-trivial amount of effort.

Not looking for an immediate but just calling it out to start thinking.

[Olshansk]

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