이 문서는 caver-js 1.5.0 또는 상위 버전을 사용하는 개발자를 위해 작성되었습니다. If you are using an older version, see .
Prerequisites
의존성
caver-js 라이브러리를 사용하려면 다음 패키지가 필요합니다.
참고 caver-js는 Node.js 버전 12와 14에서 실행 가능합니다. 권장되는 버전은 다음과 같습니다.
lts/erbium ()
lts/fermium ()
If you use a different version of the Node (for example, Node v15), utilize the Node Version Manager() to install and use the version supported by caver-js.
Installation
다음 명령을 사용해 npm으로 caver-js를 설치하세요:
$ npm install caver-js
참고: package.json 파일이 설치 경로와 동일한 곳에 존재해야 합니다. 만일 존재하지 않으면, npm init을 통해 package.json가 생성될 수 있습니다.
caver-js의 특정 버전을 설치하려면 다음 명령을 이용하세요:
$ npm install caver-js@X.X.X
Starting with caver-js
Once you have finished installing caver-js, you can now connect to a Klaytn Node using caver-js.
To practice the examples below, first create a test file in the working directory.
$ touch test.js
You can see the test.js file created in the working directory.
Write the following code in test.js.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
const version = await caver.rpc.klay.getClientVersion()
console.log(version)
}
testFunction()
Running the above code gives you the following result.
If you see the output of console.log like above, proceed with the steps below. The version number can be different according to the version of the connected Klaytn node.
Connecting to a Klaytn Node
You can import the caver-js module and connect it to a Klaytn Node in the Baobab testnet as shown in the example below:
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
If you are running an EN, you can connect it to your own node by changing the host and port like below:
const Caver = require('caver-js')
const caver = new Caver('https://your.en.url:8651/')
Managing Keyrings
Creating a Keyring
Generating a SingleKeyring
You can randomly generate a single keyring as shown below.
Creating a SingleKeyring with a private key and an address
If your private key for your Klaytn account is decoupled from the address, you can create a keyring using the given address and the given private key like below.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
// Create a keyring with an address and a private key
const keyring = caver.wallet.keyring.createWithSingleKey('0x{address in hex}', '0x{private key}')
console.log(keyring)
// Create a keyring from a KlaytnWalletKey
const keyringFromKlaytnWalletKey = caver.wallet.keyring.createFromKlaytnWalletKey('0x{private key}0x{type}0x{address in hex}')
console.log(keyringFromKlaytnWalletKey)
}
testFunction()
As you can see, _keys has multiple PrivateKey instances in the array. Member variables defined inside the instance can be accessed through keyring.address and keyring.keys.
Creating a RoleBasedKeyring with private keys
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
// Create a keyring with an address and private keys defined by each roles
const keyring = caver.wallet.keyring.createWithRoleBasedKey('0x{address in hex}', [
[ '0x{private key1}', '0x{private key2}', '0x{private key3}' ],
[ '0x{private key4}'],
[ '0x{private key5}', '0x{private key6}' ],
])
console.log(keyring)
}
testFunction()
Running the above code gives you the following result.
Looking at the output above, the first element of the keys array, roleTransactionKey, has three PrivateKey instances, and the second element, roleAccountUpdateKey, has one PrivateKey instance. And the last element of the array, roleFeePayerKey, has two PrivateKey instances.
Looking at the output above, you can query your keyring from caver.wallet after adding it to caver.wallet.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
// Add to wallet with an address and a private key
const addedSingle = caver.wallet.newKeyring('0x{address in hex}', '0x{private key1}')
console.log(caver.wallet.getKeyring(addedSingle.address))
// Add to wallet with an address and private keys
const addedMultiple = caver.wallet.newKeyring('0x{address in hex}', ['0x{private key2}', '0x{private key3}', '0x{private key4}'])
console.log(caver.wallet.getKeyring(addedMultiple.address))
// Add to wallet with an address and private keys defined by each roles
const addedRoleBased = caver.wallet.newKeyring('0x{address in hex}', [
['0x{private key5}', '0x{private key6}', '0x{private key7}'],
['0x{private key8}', '0x{private key9}'],
['0x{private key10}', '0x{private key11}']
])
console.log(caver.wallet.getKeyring(addedRoleBased.address))
}
testFunction()
Running the above code gives you the following result. The result of the above code execution is shown below. When caver.wallet.newKeyring is executed with a private key, a Keyring instance with one private key is created and added to caver.wallet. For multiple private keys, a Keyring instance with multiple private keys is created. When passing one or more private keys for each role as arguments, a Keyring instance with a different private key(s) for each role is created and also added to the caver.wallet.
caver.wallet.add or caver.wallet.newKeyring returns a Keyring instance after adding it to caver.wallet.
Sending a Transaction
This section will show you how to send KLAY using caver-js on the Baobab network.
Getting KLAY via Baobab Faucet
Sending a Value Transfer Transaction
You can use a caver-js wallet to generate a signature of a transaction. You have to go through two steps below to send the transaction to the network.
Sign a transaction
If you manage the keyring separately without adding it to caver.wallet, you can sign the transaction through transaction.sign function.
Send the RLP-encoded string of the signed transaction to the Klaytn via caver.rpc.klay.sendRawTransaction.
Note: The sender should have enough number of KLAY.
Sign a transaction
Before sending a transaction to Klaytn, you should sign a transaction first.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
// Add a keyring to caver.wallet
const keyring = caver.wallet.keyring.createFromPrivateKey('0x{private key}')
caver.wallet.add(keyring)
// Create a value transfer transaction
const valueTransfer = caver.transaction.valueTransfer.create({
from: keyring.address,
to: '0x176ff0344de49c04be577a3512b6991507647f72',
value: 1,
gas: 30000,
})
// Sign the transaction via caver.wallet.sign
await caver.wallet.sign(keyring.address, valueTransfer)
const rlpEncoded = valueTransfer.getRLPEncoding()
console.log(`RLP-encoded string: ${rlpEncoded}`)
}
testFunction()
The above code adds a keyring to caver.wallet, creates a transaction, and signs the transaction through caver.wallet.sign.
Running the above code gives you the following result. When the above code is executed, the RLP-encoded string of the transaction is shown below. (The RLP-encoded string output you got could be different from the string output shown below.)
Send the RLP-encoded string of the signed transaction to the Klaytn
Now you can send a signed transaction to the network like below. If you want to run the below example, replace 0x{RLP-encoded string} with the value of rlpEncoded above.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
const rlpEncoding = `0x{RLP-encoded string}`
// Send the transaction using `caver.rpc.klay.sendRawTransaction`.
const receipt = await caver.rpc.klay.sendRawTransaction(rlpEncoding)
console.log(receipt)
}
testFunction()
Running the above code gives you the following result. When the above code is executed, the receipt of the transaction is shown below.
If you want to sign a transaction and send it to the network without caver.wallet, see the example below.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
// Create a value transfer transaction
const keyring = caver.wallet.keyring.createFromPrivateKey('0x{private key}')
const valueTransfer = caver.transaction.valueTransfer.create({
from: keyring.address,
to: '0x176ff0344de49c04be577a3512b6991507647f72',
value: 1,
gas: 30000,
})
// Sign the transaction via transaction.sign
await valueTransfer.sign(keyring)
// Send the transaction to the Klaytn using `caver.rpc.klay.sendRawTransaction`.
const receipt = await caver.rpc.klay.sendRawTransaction(valueTransfer)
console.log(receipt)
}
testFunction()
When the above code is executed, the receipt of the transaction is printed like the previous example.
Checking Receipts
The following example shows how to get a receipt using promises and event emitters.
// Using a promise - async/await
const receipt = await caver.rpc.klay.sendRawTransaction(rawTransaction)
console.log(receipt)
// Using a promise
caver.rpc.klay.sendRawTransaction(rawTransaction).then(console.log)
// Using an event emitter
caver.rpc.klay.sendRawTransaction(rawTransaction).on('receipt', console.log)
When the above code is executed, the RLP-encoded string will be printed. (The RLP-encoded string output you got could be different from the string output shown below.)
The fee payer can send the transaction to the Klaytn after attaching the feePayerSignatures to the RLP-encoded string (rawTransaction) signed by the transaction sender. If caver.wallet also has the fee payer's key, the fee payer's signature can be injected into feeDelegatedTx by calling caver.wallet.signAsFeePayer(feePayer.address, feeDelegatedTx). Otherwise, the fee payer has to create a feeDelegatedTx from the RLP-encoded string signed by the sender and add the fee payer's sign onto it, as illustrated below. If you want to run the below example, replace 0x{RLP-encoded string} with the value of rlpEncoded above.
When the above code is executed, the RLP-encoded string including the sender's signatures and fee payer's signatures is printed like below. (The output you got could be different from the string output shown below.)
The transaction is now signed by both the sender and the fee payer, and it can now be sent over the network. Replace 0x{RLP-encoded string} with the RLP-encoded string output of the example code above.
Running the above code gives you the following result. Through the execution result of the above code, you can check the FeeDelegatedValueTransfer transaction result.
If you want to change the private key(s) for your Klaytn account, there are 3 important things you need to remember:
Klaytn validates every transaction you send to it.
The validation requires your public keys which exactly corresponds to your private key(s).
Thus, changing your private key(s) into the new one(s) is always bepreceded by changing your old public key(s) to the new one(s). The new public key(s) must be derived from the new private key(s).
Keeping the 3 things above in your mind, you can change your private key(s) by following the steps below:
Prepare the new private key(s) to create a new keyring.
Create a keyring by its type (Single keyring, Multiple keyring, or Role-based keyring) you need.
Generate an Account instance from the new keyring. This Account instance holds the new public key(s) for your Klaytn account.
Send AccountUpdate transaction including Account instance to Klaytn.
Finally, replace your old keyring to the new one that was created in Step 2.
If the above code is executed successfully, you no longer are able to use the old private key(s) to sign any transaction with the old keyring. So you must update the old keyring with the newKeyring through caver.wallet.updateKeyring(newKeyring). Once it is updated, the signing will be done by the newly updated private key(s).
Running the above code gives you the following result. In the execution result of the above code, the result of the private key and the account update that you should newly use are printed like below.
// Create an account instance with three private keys using AccountKeyWeightedMultiSig
const newPrivateKeys = caver.wallet.keyring.generateMultipleKeys(3)
const newKeyring = caver.wallet.keyring.createWithMultipleKey(sender.address, newPrivateKeys)
// threshold = 3, the weights of the three keys = [1, 2, 1]
const options = new caver.account.weightedMultiSigOptions(3, [1, 2, 1])
const account = newKeyring.toAccount(options)
// Create an account instance with roles using AccountKeyRoleBased. In the account instance created, each role has a public key that corresponds to one private key.
const newPrivateKeys = caver.wallet.keyring.generateRoleBasedKeys([1, 1, 1])
const newKeyring = caver.wallet.keyring.createWithRoleBasedKey(sender.address, newPrivateKeys)
const account = newKeyring.toAccount()
// Create an account instance with [3, 2, 3] keys for each role using AccountKeyRoleBased
const newPrivateKeys = caver.wallet.keyring.generateRoleBasedKeys([3, 2, 3])
const newKeyring = caver.wallet.keyring.createWithRoleBasedKey(sender.address, newPrivateKeys)
const options = [
// thresold = 4, weights of keys = [2, 2, 4] for roleTransactionKey
new caver.account.weightedMultiSigOptions(4, [2, 2, 4]),
// threshold = 2, weights of keys = [1, 1]
new caver.account.weightedMultiSigOptions(2, [1, 1]),
// threshold = 3, weights of keys = [1, 1, 1]
new caver.account.weightedMultiSigOptions(3, [1, 1, 1]),
]
const account = newKeyring.toAccount(options)
// Create an account with AccountKeyLegacy
const accountWithLegacyKey = caver.account.createWithAccountKeyLegacy(keyringToUpdate.address)
// Create an account with AccountKeyFail
const accountWithFailKey = caver.account.createWithAccountKeyFail(keyringToUpdate.address)
Smart Contract
First, we make a simple solidity example like the below. Create a 'test.sol' file and write down the below example.
pragma solidity ^0.5.6;
contract KVstore {
mapping(string=>string) store;
function get(string memory key) public view returns (string memory) {
return store[key];
}
function set(string memory key, string memory value) public {
store[key] = value;
}
}
Now we can compile a smart contract to get its bytecode and ABI.
Looking at the output above, you can see that the methods are managed through abi inside the Contract instance. And since it hasn't been deployed yet, you can see that the result of contractInstance.options.address is output as null.
If the smart contract has already been deployed and you know the contract address where the smart contract was deployed, please pass the contract address to the second parameter as shown below.
If you want to send a transaction with sender and feePayer signed separately when deploying a smart contract through caver.contract, refer to the code below:
If you want to send a transaction with sender and feePayer signed separately when executing a smart contract through caver.contract, refer to the code below:
When the above code is executed, the value is shown as an output below.
$ node ./test.js
testValue
Sending a Transaction with multiple signers
If the Klaytn account's AccountKey is AccountKeyMultiSig or AccountKeyRoleBased, the person who manages each key can vary.
This section describes how to collect signatures and send the transaction if there are multiple signers.
순차적으로 서명하기
When a transaction is signed using caver.wallet or the transaction's sign function, signatures (or feePayerSignatures) are defined (or appended) inside the transaction. You can obtain the RLP-encoded string (rawTransaction) containing the signatures (and feePayerSignatures) by calling the transaction.getRLPEncoding() function of the signed transaction instance.
The following example shows how to sign a transaction sequentially with multiple private keys. Let's assume that AccountKey of the account who sends this transaction is AccountKeyWeightedMultiSig of two public keys, which means this Klaytn account can use two private key strings, one private key for each user. This is a case that two users share the same Klaytn account.
In the example below, user1 and user2 create a Keyring instances to be used. After that, each uses its own keyring to sign the transaction. The example below uses transaction.sign to sign it.
Then let's see how to sign sequentially without sharing the same transaction object. In the below example, user1 passes RLP-encoded string that is the result of getRLPEncoding function of the signed transaction to user2.
The code below explains how to sign and append signatures with RLP-encoded string.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
// Create user1's keyring
const user1 = caver.wallet.keyring.createWithSingleKey('0x{address in hex}', '0x{private key1}')
// Create a value transfer transaction
const transaction = caver.transaction.valueTransfer.create({
from: user1.address,
to: '0x45c2a1e3a1c3957a06dae73ad516461c2d2c7ccc',
value: 1,
gas: 70000,
})
// Sign the transaction
await transaction.sign(user1)
// Create user2's keyring
const user2 = caver.wallet.keyring.createWithSingleKey('0x{address in hex}', '0x{private key2}')
// Create a value transfer transaction from the RLP-encoded string
const rlpEncoding = transaction.getRLPEncoding()
const transactionFromRLP = caver.transaction.valueTransfer.create(rlpEncoding)
await transactionFromRLP.sign(user2)
console.log(transactionFromRLP.signatures)
}
testFunction()
Running the above code gives you the following result.
If you run the above code, you can see that user2's signature has been appended in transactionFromRLP.signatures and a total of two signatures are included in it.
When all users have signed, send a transaction to the network through await caver.rpc.klay.sendRawTransaction(transactionFromRLP).
If you send a fee-delegated transaction, and the fee payer uses multiple keys, you can proceed with the above logic using caver.wallet.signAsFeePayer.
서명된 raw transaction들을 결합하기
If you receive multiple signed RLP-encoded raw transaction strings from several people, you can combine them into a single RLP-encoded raw transaction string that contains all the signatures.
The example below shows how to combine and send the RLP encoded transactions.
Running the code above outputs one RLP-encoded raw transaction string with all the signature information combined.
When executing combineSignedRawTransactions , the signed RLP-encoded raw transaction strings to be combined must be exactly the same to each other except the signatures and the optional variables in the transaction instance. Optional variables without any given value in the base transaction instance (the caller of combineSignedRawTransactions) will be redeemed with the corresponding ones in the following raw transaction string to be merged right next. If there is any inconsistency among all raw transaction strings including the values of optional variables of them to be merged, an error occurs.
The combineSignedRawTransactions returns an RLP-encoded string containing all signatures (and feePayerSignatures if the transaction is a fee-delegated transaction) as a result. You use this to send a transaction to the network through await caver.rpc.klay.sendRawTransaction(combined).
Detecting implementation of KCT interfaces
caver.kct provides functions that return information about which interface the given KCT token contract implements. Using this, you can see which interface the KCT token contract deployed on Klaytn implements.
Detecting KIP-7 interfaces
In order to detect the interfaces implemented by the KIP-7 token contract, you can use caver.kct.kip7.detectInterface(contractAddress) or kip7.detectInterface().
Below is a code on how to detect the implemented interfaces for the KIP-7 token contract deployed on Klaytn using static methods provided in caver.kct.kip7.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
const result = await caver.kct.kip7.detectInterface('0x{address in hex}')
console.log(result)
}
testFunction()
Running the above code gives you the following result.
In order to detect the interfaces implemented by the KIP-17 token contract, you can use caver.kct.kip17.detectInterface(contractAddress) or kip17.detectInterface().
Below is a code on how to detect the implemented interfaces for the KIP-17 token contract deployed on Klaytn using static methods provided in caver.kct.kip17.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
const result = await caver.kct.kip17.detectInterface('0x{address in hex}')
console.log(result)
}
testFunction()
Running the above code gives you the following result.
In order to detect the interfaces implemented by the KIP-37 token contract, you can use caver.kct.kip37.detectInterface(contractAddress) or kip37.detectInterface().
Below is a code on how to detect the implemented interfaces for the KIP-37 token contract deployed on Klaytn using static methods provided in caver.kct.kip37.
// test.js
const Caver = require('caver-js')
const caver = new Caver('https://public-en-baobab.klaytn.net/')
async function testFunction() {
const result = await caver.kct.kip37.detectInterface('0x{address in hex}')
console.log(result)
}
testFunction()
Running the above code gives you the following result.
is a structure that contains the address of the Klaytn account and the private key(s).
can be classified into three types depending on the type of key being stored: to store one address and one private key, to store one address and multiple private keys, and to store one address and one or more private keys for each role.
defines key property inside, and this key store one private key.
defines keys property inside, and this keys is implemented as an array to store multiple private keys.
The keys property defined in is implemented as a two-dimensional array (empty keys will look like [ [], [], [] ]) that can include multiple keys for each . The first element of the array is filled with the private key(s) to be used for roleTransactionKey, the second element the private key(s) to be used for roleAccountUpdateKey, and the third element the private key(s) to be used for roleFeePayerKey.
The result of caver.wallet.keyring.createFromPrivateKey, like the result of caver.wallet.keyring.generate above, is a instance with an address defined inside it and a [PrivateKey] instance in keyring.key.
If you want to use multiple private keys, you can create a using an address and multiple private keys. The below examples show how to create a with multiple private keys.
To use different private key(s) for each , caver.wallet.keyring.createWithRoleBasedKey is used instead. Each array element represents a role described in . The example below shows how to create a instance from different keys for each role.
Note: Calling functions related to keyring () or wallet () do not affect the actual Klaytn blockchain platform (Klaytn).
You can use a keyring easily by using the in-memory wallet provided by caver-js. The following examples illustrate how to add a keyring to a wallet using a keyring instance and a keystore file generated by .
If you have an address and private key(s) to use, you can easily create a keyring and add it directly to via .
If you need KLAY for testing, you can get Baobab testnet KLAY from the . Log in to the Klaytn Wallet using the private key or the keystore file and receive Baobab testnet KLAY via the faucet for testing.
If the keyring you want to use is added to , you can use caver.wallet.sign function to sign.
Below is an example of how to sign a transaction if a keyring is added to the .
You can use the promise or event emitter to get the receipt of the transaction when you transfer the transaction to the Klaytn by .
As described in the example above, you can get the result of sending a transaction through the promise and event emitter. The transactionHash field is defined inside the receipt object. You can use RPC call with receipt.transactionHash to query the receipt of a transaction at any time from the network after the transaction is included in a block. The example below shows how to get a receipt using the RPC call.
The result of the transaction can be found through the status of the receipt. For the details of the return values, see . If a transaction is failed, you can check more about the error in txError of the receipt. For more information about txError, see .
Klaytn provides various transaction types for extensibility and performance. For more information, see . This section describes some examples that can be used with caver-js.
Klaytn provides feature. Here's an example of making a RLP-encoded transaction when you are a sender of this kind of transaction:
Please check for the details.
To change your AccountKey, you must provide an instance for the account field in the input argument object of caver.transaction.accountUpdate. An instance contains the address of the Klaytn account and the AccountKey to be updated.
The code below is an example code that changes the private key(s) you use for your Klaytn account along with changing AccountKey of your Klaytn account to . Don't forget to prepare your new private key(s).
Here comes how to update AccountKey of your Klaytn account with multiple [AccountKeys]? The example below explains how to create an instance with multiple private keys that what you want to use (You can create an instance with multiple public keys via ). Same again, after feeding the account instance created to the account field inside the transaction object, the left rest of the updating process is just the same as the above example.
First, let's create an Account instance to update with . For , a threshold and a weight for each key must be defined. To do this, use . The first parameter is the threshold, and the second parameter is an array containing the weight for each key.
Now let's update AccountKey using . is an AccountKey type that defines the key to use for each .
The AccountKeyRoleBased above is an example of using one public key for each role. As you can see from the code above, each of them corresponds to one private key. If you want to use multiple private keys for each role, must be defined for each role as shown below.
If you want to update AccountKey to or , create an Account instance as shown below and assign it to the account field of the transaction.
The package makes it easy to interact with smart contracts on Klaytn. It automatically converts all methods of a smart contract into javascript calls when its low-level ABI (Application Binary Interface) is given. This allows you to interact with smart contracts as if they were JavaScript objects.
NOTE: To compile a smart contract, you must have a installed.
For the smart contract deployment, you can use to deploy it, or you can deploy it using , or transaction. Here is an example of using .
Note that sends transactions for deployment and execution. It uses keyrings in caver.wallet to sign transactions. The keyring to be used must be added to caver.wallet before.
A smart contract can be executed using one of the followings, depending on the type of contract executing transaction: Contract class in caver.contract or , , or . To send a transaction for executing a smart contract:
To find more information, see .
To run this example, you need to update AccountKey of the Klaytn account you use for testing with . Please refer to for how to update your Klaytn account.
Running the above code gives you the following result. Looking at the execution result of the code above, if user1 signs, one signature is created. If user2 signs, user2's signature is appended. is an object that stores a signature.
