Sol and SPL-Token Transfer #10

Open
opened 2024-11-24 23:24:22 +00:00 by ryan · 11 comments
Owner

Stages:

  • Define Module Interfaces
    • Transaction generation
      • Transfer
      • Token Account Creation
      • Token Transfer
      • Stake
      • Unstake
    • Transaction validation
    • Transaction signing
    • Transaction broadcasting
  • Create standardized derivation paths in Keyfork
  • Implement Module Interfaces
    • Transaction generation
      • Transfer
      • Token Account Creation
      • Token Transfer
      • Stake
      • Unstake
    • Transaction validation
    • Transaction signing
    • Transaction broadcasting
Stages: - [X] Define Module Interfaces - [ ] Transaction generation - [X] Transfer - [X] Token Account Creation - [X] Token Transfer - [ ] Stake - [ ] Unstake - [ ] Transaction validation - [x] Transaction signing - [x] Transaction broadcasting - [x] Create standardized derivation paths in Keyfork - [ ] Implement Module Interfaces - [x] Transaction generation - [X] Transfer - [X] Token Account Creation - [X] Token Transfer - [ ] Stake - [ ] Unstake - [ ] Transaction validation - [x] Transaction signing - [x] Transaction broadcasting
ryan added this to the Custody Framework project 2024-11-24 23:24:23 +00:00
ryan added the due date 2024-12-15 2024-11-25 21:44:20 +00:00
ryan added a new dependency 2024-11-25 21:45:32 +00:00
ryan added a new dependency 2024-11-25 21:50:03 +00:00
Author
Owner

Progress update: icepick-solana can now generate SystemProgram transfer transactions. The blob returned contains a JSON serialized blob that should be parseable by the next program. This also means I need to add blob parsing systems into Icepick operation blobs.

Progress update: `icepick-solana` can now generate SystemProgram transfer transactions. The blob returned contains a JSON serialized blob that should be parseable by the next program. This also means I need to add blob parsing systems into Icepick operation blobs.
Author
Owner

Blob parsing has been added. CLI will block if input is not a TTY to read a JSON value containing the output of the previous command. This also means we now have a system to get derived keys that we can pass to modules, since we can parse the non-blob content of the module i.e. {"blob": <whatever>, "derivation_paths": ["m/44'/501'/0'/0'"]} gets sent to application like {"blob": <whatever>, "derived_keys": [[<key as u8 array>]]}

Blob parsing has been added. CLI will block if input is not a TTY to read a JSON value containing the output of the previous command. This also means we now have a system to get derived keys that we can pass to modules, since we can parse the non-`blob` content of the module i.e. `{"blob": <whatever>, "derivation_paths": ["m/44'/501'/0'/0'"]}` gets sent to application like `{"blob": <whatever>, "derived_keys": [[<key as u8 array>]]}`
Author
Owner

Keys could also be base64 and take up a lot less space, but would require to/from de/serialization.

Keys could also be base64 and take up a lot less space, but would require to/from de/serialization.
Author
Owner
https://docs.rs/serde_with/latest/serde_with/base64/struct.Base64.html solution found
ryan added a new dependency 2024-11-26 16:57:38 +00:00
Author
Owner
     Running `/tmp/cargo-target/debug/icepick sol sign`
[crates/by-chain/icepick-solana/src/lib.rs:282:17] BASE64_STANDARD.encode(transaction.message_data()) = "AQABA4iPRr5lC5pr4P8V8oo/AOkCRb6e9KQvL1t8mQ+5DMDKY5i9FzNsZBmadJSmN0t0PpNE89qbEpwlaA8AYNhvuPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFYKDREtZJIsFFFFNooaPoSdj5VlJg/f5p5pSqStwWViAQICAAEMAgAAAKCGAQAAAAAA"

A Keyfork-generated key, built using #17, sending SOL to another Keyfork-generated key. The transaction itself can be parsed by blockchain explorer but I can't verify the signatures using the explorer. Transaction broadcast is up next, and likely also a command to get a recent blockhash.

``` Running `/tmp/cargo-target/debug/icepick sol sign` [crates/by-chain/icepick-solana/src/lib.rs:282:17] BASE64_STANDARD.encode(transaction.message_data()) = "AQABA4iPRr5lC5pr4P8V8oo/AOkCRb6e9KQvL1t8mQ+5DMDKY5i9FzNsZBmadJSmN0t0PpNE89qbEpwlaA8AYNhvuPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFYKDREtZJIsFFFFNooaPoSdj5VlJg/f5p5pSqStwWViAQICAAEMAgAAAKCGAQAAAAAA" ``` A Keyfork-generated key, built using #17, sending SOL to another Keyfork-generated key. The transaction itself can be parsed by blockchain explorer but I can't verify the signatures using the explorer. Transaction broadcast is up next, and likely also a command to get a recent blockhash.
Author
Owner

https://explorer.solana.com/tx/5jA97YEGipBggDyc43U72wsMcsmeVKDac6eokcXbuGTiketKLUqwgC32yM9gg5FNH9iCYvSYtrg7J1NsaH9Z4V5u?cluster=devnet

{
  "blob": {
    "status": "send_and_confirm",
    "succcess": "5jA97YEGipBggDyc43U72wsMcsmeVKDac6eokcXbuGTiketKLUqwgC32yM9gg5FNH9iCYvSYtrg7J1NsaH9Z4V5u"
  }
}
https://explorer.solana.com/tx/5jA97YEGipBggDyc43U72wsMcsmeVKDac6eokcXbuGTiketKLUqwgC32yM9gg5FNH9iCYvSYtrg7J1NsaH9Z4V5u?cluster=devnet ```json { "blob": { "status": "send_and_confirm", "succcess": "5jA97YEGipBggDyc43U72wsMcsmeVKDac6eokcXbuGTiketKLUqwgC32yM9gg5FNH9iCYvSYtrg7J1NsaH9Z4V5u" } } ```
Author
Owner

Minor update: I was working on seeing if I could reproduce an Icepick key using the Solana CLI and vice versa, and I encountered a strange hiccup. The Solana key management utilities use BIP-0039 mnemonics but don't use hierarchical derivation. This means that while Solana looks like it can accept mnemonics, it doesn't conform to the pattern of "use bip39 to get bip32 seed, use bip32/slip10".

In actuality, what happens when running solana-keygen recover is:

  1. bip39 mnemonic is interpreted
  2. the bip32 seed is generated
  3. the Keypair::from_seed() constructor just takes the first 32 bits and trashes the rest

This means most keys generated by the Solana CLI can't be used by Icepick. That doesn't necessarily mean Icepick can't generate keys consumable by the Solana CLI - that functionality will likely have to exist anyways at some point for conformance testing.

Minor update: I was working on seeing if I could reproduce an Icepick key using the Solana CLI and vice versa, and I encountered a strange hiccup. The Solana key management utilities use BIP-0039 mnemonics but _don't_ use hierarchical derivation. This means that while Solana looks like it can accept mnemonics, it doesn't conform to the pattern of "use bip39 to get bip32 seed, use bip32/slip10". In actuality, what happens when running `solana-keygen recover` is: 1. bip39 mnemonic is interpreted 2. the bip32 seed is generated 3. the [Keypair::from_seed() constructor][constructor] just takes the first 32 bits and trashes the rest This means most keys generated by the Solana CLI can't be used by Icepick. That doesn't necessarily mean Icepick can't generate keys consumable by the Solana CLI - that functionality will likely have to exist anyways at some point for conformance testing. [constructor]: https://github.com/anza-xyz/agave/blob/79c0fe5c7cfc94e921a104c4e51e2e27aee9d821/sdk/keypair/src/lib.rs#L269-L278
Author
Owner

SPL-Token checkpoint: I had some issues with the Instruction compiler not marking the "from" pubkey as writable, to pay fees, in the event a payer is not provided. This has been resolved.

This is likely resolved in the CLI by using the Set Computation Budget thing I noticed earlier, but was not listed as required.

SPL-Token checkpoint: I had some issues with the Instruction compiler not marking the "from" pubkey as writable, to pay fees, in the event a payer is not provided. This has been resolved. This is likely resolved in the CLI by using the Set Computation Budget thing I noticed earlier, but was not listed as required.
Author
Owner
Base of `icepick sol transfer-token` has been committed. Devnet testing: https://explorer.solana.com/tx/64Qu7qSBXTtpouNVjDw2h2EwGuimn4CuhpLjUYFvVYReBakQdhAwsFpRfSTeK6vJ8rfZ1nZ5g4orLop589dw8quG?cluster=devnet
ryan self-assigned this 2024-12-05 19:46:11 +00:00
Author
Owner

blockhash has been removed from all commands that generate transaction. The blockhash is instead provided to the sign subcommand, which is the step between "generating (possibly online) and validating the transaction", which means the only time sensitive portion is: get blockhash (online) --> sign (offline) --> broadcast (online).

`blockhash` has been removed from all commands that generate transaction. The blockhash is instead provided to the `sign` subcommand, which is the step between "generating (possibly online) and validating the transaction", which means the only time sensitive portion is: get blockhash (online) --> sign (offline) --> broadcast (online).
ryan added this to the Icepick v0.1.0 milestone 2024-12-12 20:30:36 +00:00
Author
Owner

End to end tests have been added as of 44aef0ca99.

End to end tests have been added as of 44aef0ca99ca5763f5ccd629af39130fb66e9004.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

2024-12-15

Reference: public/icepick#10
No description provided.