Recording on Youtube:
Dial in Information is at: https://casperlabs.atlassian.net/wiki/spaces/REL/pages/136544674/Weekly%2BWorkshops%2BHome
Ledger Leap (Stefan & Thomas)
Thomas
During this workshop, we will demonstrate CasperLabs' flexible multi-signature functionality within smart contracts. We will demonstrate the ‘threshold’ feature within an account, and how keys with sufficient weight can sign a deploy to meet a threshold, and how deploys can be sent for signature using the CasperLabs client.
Demonstrate the capability of CasperLabs weighted keys
Install the client
Build the contracts
Send the deploy via email to someone for signature
Send the deploy once it has the second signature.
We will record the session.
Create some keys
View the default weights for the key.
Update the key thresholds to 2 using a deployment
Update the deployment thresholds to 2 using a deployment
View the weights.
Create a transfer deployment, sign it and send it to someone.
Other signatory signs the deploy & sends it via the client.
Observe that a single signer cannot complete the deployment (transfer)
Clone the repository on your machine
git clone -b dev https://github.com/CasperLabs/CasperLabs.git |
2. Install the CasperLabs client using brew, apt, docker or tarball ….
3. Compile contracts
cd execution-engine make setup make build-contracts |
4. Let’s look at the weight of Key1 - go to clarity.casperlabs.io and look at GraphQL
Let’s get the latest block:
query { dagSlice(depth: 1) { blockHash } } |
Now - let’s open a new tab in GraphQL and lets examine the account associated with Key1 : Use Graph QL to see the keys associated with the contract. Obtain your Hex key and replace it in keyBase16 - and the latest block hash in ‘blockHashBase16Prefix’ and then run this graphQL query.
query { globalState( blockHashBase16Prefix: "The latest block hash" StateQueries: [ { keyType: Address keyBase16: "Your Hex Key" pathSegments: [] } ] ) { value { __typename ... on Account { pubKey associatedKeys { pubKey weight } actionThreshold { deploymentThreshold keyManagementThreshold } } } } } |
You should see a result that looks like this:
{ "data": { "globalState": [ { "value": { "__typename": "Account", "pubKey": "3eaaf54978990c040150bf3b98e0128a3aab24d1bb1b484956678673531387fe", "associatedKeys": [ { "pubKey": "3eaaf54978990c040150bf3b98e0128a3aab24d1bb1b484956678673531387fe", "weight": 1 } ], "actionThreshold": { "deploymentThreshold": 1, "keyManagementThreshold": 1 } } } ] } } |
To prevent being locked out of the account, you must add a key that has more weight than the key management threshold (which must be increased prior to increasing the deployment threshold)
export NEW_KEY_HEX=[hex value of the new key to add] export KEYWT=5 export KARGS="[\ {\"name\": \"method\", \"value\": {\"string_value\": \"set_key_weight\"}}, \ {\"name\": \"target-account\", \"value\": {\"bytes_value\": \"${NEW_KEY_HEX}\"}}, \ {\"name\": \"weight\", \"value\": {\"bytes_value\": \"${KEYWT}\"}} \ ]" |
casperlabs-client --host deploy.casperlabs.io deploy --session [path to session file] --session-args "${KARGS}" --payment-amount 10000000 --private-key [path to private key] |
(the path for the contract under CasperLabs is ‘execution-engine/target/wasm32-unknown-unknown/release/keys_manager.wasm’)
7. Now we will update the thresholds for the account of Key1. NOTE: the key_management threshold must be equal or greater to the deployment_threshold. This is a safety measure which prevents the account from being locked out.
export KEYTH="set_key_management_threshold" export KTHRESH=3 export KTARGS="[\ {\"name\": \"method\", \"value\": {\"string_value\": \"${KEYTH}\"}}, \ {\"name\": \"weight\", \"value\": {\"bytes_value\": \"${KTHRESH}\"}} \ ]" |
Run the deployment:
casperlabs-client --host deploy.casperlabs.io deploy --session [path to wasm file keys_manager.wasm] --session-args "${KTARGS}" --payment-amount 10000000 --private-key [path to your private key1] |
Confirm the deploy worked.
Check the values in GraphQL - you should see a new key management threshold.
8. Now update the deployment thresholds for the account. This will authorize only key2 to perform the token transfer.
export DEPTH=set_deployment_threshold export DTHRESH=2 export DTARGS="[\ {\"name\": \"method\", \"value\": {\"string_value\": \"${DEPTH}\"}}, \ {\"name\": \"weight\", \"value\": {\"bytes_value\": \"${DTHRESH}\"}} \ ]" |
Repeat the GraphQL queries by getting the latest block hash.
casperlabs-client --host deploy.casperlabs.io deploy --session [path to wasm file keys_manager.wasm] --session-args "${DTARGS}" --payment-amount 10000000 --from "public key1" --private-key [path to your private key2] |
Upon completing this deployment, Key1 will not be authorized to sign a token transfer.
Let’s export our arguments for the token transfer.
export TO_HEX="base16-of-key3" export AMOUNT="56" export TXARGS="[\ {\"name\": \"target-account\", \"value\": {\"bytes_value\": \"${TO_HEX}\"}}, \ {\"name\": \"amount\", \"value\": {\"long_value\": \"${AMOUNT}\"}} \ ]" |
Now we will create the deployment, sign it and send it for a second signature. We will sign this deployment with Key 1
casperlabs-client make-deploy --session [path to wasm file transfer_to_account.wasm] --session-args "${TXARGS}" --payment-amount 10000000 --from [base16 public key for (key1)] -o transfer_test.deploy |
Then send this file via a mechanism (scp, email) to someone else, or input it into the process to sign the deployment. This deploy is signed with 1 key. It will need another key (assuming both keys have a weight of 1) in order to process against the account.
casperlabs-client sign-deploy -i [path to transfer_test.deploy] --public-key [path to public key 1] --private-key [path to private key 1] -o signed_transfer_test.deploy |
Send the deployment to the second party to sign. You can send the deploy by whatever mechanism you wish.
casperlabs-client sign-deploy -i [path to signed_transfer_test.deploy] --public-key [path to public key 2] --private-key [path to private key 2] -o ready_transfer_test.deploy |
Now the deployment could be sent by party 2 if they wish.
casperlabs-client --host deploy.casperlabs.io send-deploy -i ready_transfer_test.deploy |
Observe that the token transfer succeeds and token lands in the account3 balance.
CasperLabs Client 0.11.0 (5777274434bf8cb676c43b0a0ca28f4e015c683e)
Deployed to DevNet
Key weights work with thresholds. Any number of authorized keys can be used in combination to sign a deployment to meet a deploy threshold.
The key_management threshold must be equal or greater to the deployment_threshold. This is a safety measure which prevents the account from being locked out.
If the keys signing a deployment lack the sufficient weight to meet the threshold, the deployment fails to run on the node. Users do not get an error message about this. They observe that the transaction never appears in a block.
Title | Description | Notes |
---|---|---|
Verify pre-requisites | Check that everyone has managed to get through the setup. | Does everyone have keys in Clarity? Has everyone cloned the repository and built the contracts? Does everyone have the client installed? What is the version number for the Client? |
If you want to unwind the change to the thresholds, just repeat the process and reset the weights back to the defaults.
You can also attempt to remove the associated key also if you wish, after you have reduced the deployment thresholds and key management thresholds.
Go to Discord- we will help you there: https://discord.gg/mpZ9AYD
We need to figure out how users can see that they hit an authorization error. No block is created, because the deploy isn’t authorized, and this presently only shows up on the server logs. App developers may need to check that they don’t send a deploy until the requisite key weights are in place.