You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* added keypair
* add a note about keypair to the readme
* formatting
* fix type in readme
* remove keypair
* add keypair back
* remove keypair
* add keypair back
* rename keypair
The PDA account address (derived from seeds `b"meta"` and canonical bump) is
10
+
9
11
```
10
12
2f9SLuUNb7TNeM6gzBwT4ZjbL5ZyKzzHg1Ce9yiquEjj
11
13
```
12
14
13
15
The PDA account address (derived from seeds `b"rent-payer")
16
+
14
17
```
15
18
Am1aA3XQciu3vMG6E9yLa2Y9TcTf2XB3D3akLtjVzu3L
16
19
```
17
20
21
+
**Important Note**: The keypair in this repository is public and is used only
22
+
for development purposes. It should not be used on testnet or mainnet
23
+
environments.
18
24
19
25
# Introduction
20
26
21
-
This repository hosts the smart contract (program) deployed on the Solana network to enable ZetaChain's cross-chain functionality. It consists of a single program that supports the following actions:
27
+
This repository hosts the smart contract (program) deployed on the Solana
28
+
network to enable ZetaChain's cross-chain functionality. It consists of a single
29
+
program that supports the following actions:
22
30
23
-
1. Users on the Solana network can send SOL to the program to deposit into ZetaChain, with the option to invoke a ZetaChain EVM contract.
24
-
2. Contracts on the ZetaChain EVM can withdraw SOL to users on the Solana network.
31
+
1. Users on the Solana network can send SOL to the program to deposit into
32
+
ZetaChain, with the option to invoke a ZetaChain EVM contract.
33
+
2. Contracts on the ZetaChain EVM can withdraw SOL to users on the Solana
34
+
network.
25
35
26
36
# Build and Test Instructions
27
37
28
-
Prerequisites: a recent version of `rust` compiler and `cargo` package manger must be installed. The program is built with the `anchor` framework so it needs to be installed as well; see [installation](https://www.anchor-lang.com/docs/installation)
38
+
Prerequisites: a recent version of `rust` compiler and `cargo` package manger
39
+
must be installed. The program is built with the `anchor` framework so it needs
@@ -37,8 +52,9 @@ $ sh -c "$(curl -sSfL https://release.anza.xyz/v2.1.0/install)"
37
52
```
38
53
39
54
To show the installed versions of the tools
55
+
40
56
```bash
41
-
$ olana --version
57
+
$ solana --version
42
58
solana-cli 2.1.0
43
59
44
60
$ rustc --version
@@ -49,61 +65,104 @@ anchor-cli 0.31.1
49
65
```
50
66
51
67
To build (this will require at least 2GB disk space)
68
+
52
69
```bash
53
70
$ anchor build
54
71
```
55
72
56
73
To run the tests
74
+
57
75
```bash
58
76
$ anchor test
59
77
```
60
78
61
-
To generate Go bindings for program's IDL
62
-
Development environments : Localnet
79
+
To generate Go bindings for program's IDL Development environments : Localnet
80
+
63
81
```bash
64
82
$ make generate-dev
65
83
```
66
84
67
85
Production environments : Mainnet,Testnet
86
+
68
87
```bash
69
88
$ make generate-prod
70
89
```
71
90
72
91
# Authentication and Authorization
73
92
74
-
Anyone can deposit and remote invoke ZetaChain contracts.
75
-
76
-
Only ZetaChain TSS account can call `withdraw` on the program. The ZetaChain TSS account is a collection of Observer/Signers which uses ECDSA TSS (Threshold Signature Scheme) to sign outbound transactions. The TSS address will appear in this program a single ECDSA secp256k1 address; but it does not have a single private key, rather its private key consists of multiple key shares and they collectively sign a message in a KeySign MPC ceremony. The program authenticates via verifying the TSS signature and is authorized by ZetaChain to perform outbound transactions as part of ZetaChain cross-chain machinery.
77
-
78
-
The ZetaChain TSS is on ECDSA secp256k1 curve; But Solana native digital signature scheme is EdDSA Ed25519 curve. Therefore the program uses custom logic to verify the TSS ECDSA signature (like alternative authentication in smart contract wallet); the native transaction signer (fee payer on Solana) does not carry authorization and it's only used to build the transaction and pay tx fees. There are no restrictions on who the native transaction signer/fee payer is. The following code excerpt is for authenticating TSS signature in the contract itself, using the [Rust secp256k1 library bundled with solana](https://docs.rs/solana-program/latest/solana_program/secp256k1_recover/index.html): https://github.com/zeta-chain/protocol-contracts-solana/blob/01eeb9733a00b6e972de0578b0e07ebc5837ec54/programs/protocol-contracts-solana/src/lib.rs#L116-L121
79
-
80
-
The function `recover_eth_address` is implemented in the gateway program: https://github.com/zeta-chain/protocol-contracts-solana/blob/01eeb9733a00b6e972de0578b0e07ebc5837ec54/programs/protocol-contracts-solana/src/lib.rs#L180-L196
81
-
82
-
The TSS signature is a ECDSA secp256k1 signature; its public key therefore address (Ethereum compatible hashing from pubkey) is therefore verifiable using the `secp256k1_recover` function. Alternatively, Solana runtime also provides a program to provide this verification service via CPI; see [proposal 48](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0048-native-program-for-secp256r1-sigverify.md) which might be more cost efficient.
83
-
84
-
In the instruction, the ECDSA signed message_hash must commit to the `nonce`, `amount`, and `to` address. See the check in these instructions like: https://github.com/zeta-chain/protocol-contracts-solana/blob/01eeb9733a00b6e972de0578b0e07ebc5837ec54/programs/protocol-contracts-solana/src/lib.rs#L110-L114 The commitment of `nonce` in the signature prevents replay of the TSS ECDSA signed message. Also (to be added in https://github.com/zeta-chain/protocol-contracts-solana/issues/6) a chain id of Solana should be added to the commitment of the message hash, so that the signature cannot be replayed on *other blockchains* that potentially uses similar authentication (say in TON).
85
-
93
+
Anyone can deposit and remote invoke ZetaChain contracts.
94
+
95
+
Only ZetaChain TSS account can call `withdraw` on the program. The ZetaChain TSS
96
+
account is a collection of Observer/Signers which uses ECDSA TSS (Threshold
97
+
Signature Scheme) to sign outbound transactions. The TSS address will appear in
98
+
this program a single ECDSA secp256k1 address; but it does not have a single
99
+
private key, rather its private key consists of multiple key shares and they
100
+
collectively sign a message in a KeySign MPC ceremony. The program authenticates
101
+
via verifying the TSS signature and is authorized by ZetaChain to perform
102
+
outbound transactions as part of ZetaChain cross-chain machinery.
103
+
104
+
The ZetaChain TSS is on ECDSA secp256k1 curve; But Solana native digital
105
+
signature scheme is EdDSA Ed25519 curve. Therefore the program uses custom logic
106
+
to verify the TSS ECDSA signature (like alternative authentication in smart
107
+
contract wallet); the native transaction signer (fee payer on Solana) does not
108
+
carry authorization and it's only used to build the transaction and pay tx fees.
109
+
There are no restrictions on who the native transaction signer/fee payer is. The
110
+
following code excerpt is for authenticating TSS signature in the contract
111
+
itself, using the [Rust secp256k1 library bundled with
The commitment of `nonce` in the signature prevents replay of the TSS ECDSA
129
+
signed message. Also (to be added in
130
+
https://github.com/zeta-chain/protocol-contracts-solana/issues/6) a chain id of
131
+
Solana should be added to the commitment of the message hash, so that the
132
+
signature cannot be replayed on \_other blockchains* that potentially uses
133
+
similar authentication (say in TON).
86
134
87
135
# Relevant Account and Addresses
88
136
89
-
The Gateway program derives a PDA (Program Derived Address) with seeds `b"meta"` and canonical bump. This PDA account/address actually holds the SOL balance of the Gateway program. For SPL tokens, the program stores the SPL token in PDA derived ATAs. For each SPL token (different mint account), the program creates an ATA from the PDA and the Mint (standard way of deriving ATA in Solana SPL program).
137
+
The Gateway program derives a PDA (Program Derived Address) with seeds `b"meta"`
138
+
and canonical bump. This PDA account/address actually holds the SOL balance of
139
+
the Gateway program. For SPL tokens, the program stores the SPL token in PDA
140
+
derived ATAs. For each SPL token (different mint account), the program creates
141
+
an ATA from the PDA and the Mint (standard way of deriving ATA in Solana SPL
142
+
program).
90
143
91
-
The PDA account itself is a data account that holds Gateway program state, namely the following data types https://github.com/zeta-chain/protocol-contracts-solana/blob/01eeb9733a00b6e972de0578b0e07ebc5837ec54/programs/protocol-contracts-solana/src/lib.rs#L271-L275
144
+
The PDA account itself is a data account that holds Gateway program state,
The `nonce` is incremented on each successful withdraw transaction, and it's used to prevent replay of signed ECDSA messages.
94
-
The `tss_address` is the TSS address of ZetaChain (20Bytes, Ethereum style). `authority` is the one who can update the TSS address stored in PDA account.
95
-
The `initialize` instruction sets nonce to 0.
148
+
The `nonce` is incremented on each successful withdraw transaction, and it's
149
+
used to prevent replay of signed ECDSA messages. The `tss_address` is the TSS
150
+
address of ZetaChain (20Bytes, Ethereum style). `authority` is the one who can
151
+
update the TSS address stored in PDA account. The `initialize` instruction sets
152
+
nonce to 0.
96
153
97
154
# Troubleshooting
98
155
99
156
## MacOS error when running `anchor test` or `solana-test-validator`
100
157
101
158
If you see errors like
159
+
102
160
```
103
161
Unable to get latest blockhash. Test validator does not look started. Check ".anchor/test-ledger/test-ledger-log.txt" for errors. Consider increasing [test.startup_wait] in Anchor.toml.
104
162
```
105
163
106
-
or
164
+
or
165
+
107
166
```bash
108
167
% solana-test-validator --reset
109
168
Ledger location: test-ledger
@@ -113,21 +172,24 @@ Error: failed to start validator: Failed to create ledger at test-ledger: io err
113
172
114
173
This is because the BSD tar program is not compatible with the GNU tar program.
115
174
116
-
To fix the issue: install GNU tar program using homebrew and export it's executable path in your `.zshrc` file:
175
+
To fix the issue: install GNU tar program using homebrew and export it's
0 commit comments