Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solana (phantom wallet) support #48

Merged
merged 8 commits into from
Apr 8, 2024
Merged

Solana (phantom wallet) support #48

merged 8 commits into from
Apr 8, 2024

Conversation

XuJiandong
Copy link
Owner

@XuJiandong XuJiandong commented Mar 28, 2024

Overall Procedure:

  1. After receiving the transaction (tx), the dApp calculates the signing message hash (32 bytes).
  2. The dApp calls the API at https://docs.phantom.app/solana/signing-a-message. The format of the signed string is as follows:
CKB transaction: 0x<signing message hash, in hexadecimal format>

For example:

CKB transaction: 0x0011223344556677001122334455667700112233445566770011223344556677
  1. The dApp combines the signature and pubkey together and fills in the signature field of OmniLockWitnessLock. The signature is 64 bytes, and the pubkey is 32 bytes, totaling 96 bytes. They have a specific order: the signature comes first, followed by the pubkey. Then, the dApp sends the tx to the p2p network.
  2. During contract verification, the signature field of OmniLockWitnessLock is first obtained and parsed into two parts: signature and pubkey.
  3. The blake160 hash of the pubkey is verified to match the 20-byte auth content. In solana, the 32 bytes pubkey can be decoded from address via base58. Unlike other blockchains, it's not an pubkey hash and can't be fit into 20 bytes auth content. So there is an blake160 hash on pubkey.
  4. The contract calculates the signing message hash, converts it to hexadecimal format, and adds the prefix "CKB transaction: 0x ". This becomes the ed25519 message. Note that this message can be of any length and does not require hashing.
  5. For the ed25519 message, signature, and pubkey, the ed25519 verify function is used. If the verification passes, the signature is successfully verified.

Other notes:

  • The blake160 hash is the leading 20 bytes of blake2b hash with personalization: "ckb-default-hash".
  • A Solana address is a straightforward base58 encoding of a 32-byte ed25519 public key. Unlike Bitcoin and Ethereum, no hashing is involved.
  • Unlike secp256k1, an ed25519 signature cannot independently recover the public key. Therefore, both the signature and an additional public key are required for validation.

Other changes:

  • Optimize get_witness_layout
  • Add test cases for cycles consuming

* make tx possible without radomness
* add ed25519 library
* avoid duplicated verifications on witnesses
* printf with format %zu for size_t
message calculation flow is not part of cobuild protocol.
Some of lock scripts may need this.
@XuJiandong XuJiandong merged commit 2a04f15 into cobuild Apr 8, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant