github.com/muhammedhassanm/blockchain@v0.0.0-20200120143007-697261defd4d/sawtooth-core-master/docs/source/cli/sawtooth.rst (about) 1 .. 2 Copyright 2017 Intel Corporation 3 4 Licensed under the Apache License, Version 2.0 (the "License"); 5 you may not use this file except in compliance with the License. 6 You may obtain a copy of the License at 7 8 http://www.apache.org/licenses/LICENSE-2.0 9 10 Unless required by applicable law or agreed to in writing, software 11 distributed under the License is distributed on an "AS IS" BASIS, 12 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 See the License for the specific language governing permissions and 14 limitations under the License. 15 16 .. _sawtooth-cli-reference-label: 17 18 ******** 19 sawtooth 20 ******** 21 22 The ``sawtooth`` command is the usual way to interact with validators or 23 validator networks. 24 25 This command has a multi-level structure. It starts with the base call to 26 ``sawtooth``. Next is a top-level subcommand such as ``block`` or ``state``. 27 Each top-level subcommand has additional subcommands that specify the 28 operation to perform, such as ``list`` or ``create``. The subcommands have 29 options and arguments that control their behavior. For example: 30 31 .. code-block:: console 32 33 $ sawtooth state list --format csv 34 35 .. literalinclude:: output/sawtooth_usage.out 36 :language: console 37 38 sawtooth batch 39 ============== 40 41 The ``sawtooth batch`` subcommands display information about the 42 Batches in the current blockchain and submit Batches to the validator 43 via the REST API. A Batch is a group of interdependent transactions 44 that is the atomic unit of change in Sawtooth. For more information, 45 see “Transactions and Batches!” 46 47 48 .. literalinclude:: output/sawtooth_batch_usage.out 49 :language: console 50 51 sawtooth batch list 52 =================== 53 54 The ``sawtooth batch list`` subcommand queries the specified Sawtooth 55 REST API (default: ``http://localhost:8008``) for a list of Batches in 56 the current blockchain. It returns the id of each Batch, the public 57 key of each signer, and the number of transactions in each Batch. 58 59 By default, this information is displayed as a white-space delimited 60 table intended for display, but other plain-text formats (CSV, JSON, 61 and YAML) are available and can be piped into a file for further 62 processing. 63 64 65 .. literalinclude:: output/sawtooth_batch_list_usage.out 66 :language: console 67 68 sawtooth batch show 69 =================== 70 71 The ``sawtooth batch show`` subcommand queries the Sawtooth REST API 72 for a specific batch in the current blockchain. It returns complete 73 information for this batch in either YAML (default) or JSON format. 74 Use the ``--key`` option to narrow the returned 75 information to just the value of a single key, either from the batch 76 or its header. 77 78 This subcommand requires the URL of the REST API (default: 79 ``http://localhost:8008``), and can specify a `username`:`password` 80 combination when the REST API is behind a Basic Auth proxy. 81 82 83 .. literalinclude:: output/sawtooth_batch_show_usage.out 84 :language: console 85 86 sawtooth batch status 87 ===================== 88 89 The ``sawtooth batch status`` subcommand queries the Sawtooth REST API 90 for the committed status of one or more batches, which are specified 91 as a list of comma-separated Batch ids. The output is in either YAML 92 (default) or JSON format, and includes the ids of any invalid 93 transactions with an error message explaining why they are invalid. 94 The ``--wait`` option indicates that results should not be returned 95 until processing is complete, with an optional timeout value specified 96 in seconds. 97 98 This subcommand requires the URL of the REST API (default: 99 ``http://localhost:8008``), and can specify a `username`:`password` 100 combination when the REST API is behind a Basic Auth proxy. 101 102 .. literalinclude:: output/sawtooth_batch_status_usage.out 103 :language: console 104 105 sawtooth batch submit 106 ===================== 107 108 The ``sawtooth batch submit`` subcommand sends one or more Batches to 109 the Sawtooth REST API to be submitted to the validator. The input is a 110 binary file with a binary-encoded ``BatchList`` protobuf, which can 111 contain one or more batches with any number of transactions. The 112 ``--wait`` option indicates that results should not be returned until 113 processing is complete, with an optional timeout specified in seconds. 114 115 This subcommand requires the URL of the REST API (default: 116 ``http://localhost:8008``), and can specify a `username`:`password` 117 combination when the REST API is behind a Basic Auth proxy. 118 119 120 .. literalinclude:: output/sawtooth_batch_submit_usage.out 121 :language: console 122 123 sawtooth block 124 ============== 125 126 The ``sawtooth block`` subcommands display information about the 127 blocks in the current blockchain. 128 129 .. literalinclude:: output/sawtooth_block_usage.out 130 :language: console 131 132 sawtooth block list 133 =================== 134 135 The ``sawtooth block list`` subcommand queries the Sawtooth REST API 136 (default: ``http://localhost:8008``) for a list of blocks in the 137 current chain. Using the ``--count`` option, the number of blocks returned can 138 be configured. It returns the id and number of each block, the public key of 139 each signer, and the number of transactions and batches in each. 140 141 By default, this information is displayed as a white-space delimited 142 table intended for display, but other plain-text formats (CSV, JSON, 143 and YAML) are available and can be piped into a file for further 144 processing. 145 146 .. literalinclude:: output/sawtooth_block_list_usage.out 147 :language: console 148 149 sawtooth block show 150 =================== 151 152 The ``sawtooth block show`` subcommand queries the Sawtooth REST API 153 for a specific block in the current blockchain. It returns complete 154 information for this block in either YAML (default) or JSON format. 155 Using the ``--key`` option, it is possible to narrow the returned 156 information to just the value of a single key, either from the block, 157 or its header. 158 159 This subcommand requires the URL of the REST API (default: 160 ``http://localhost:8008``), and can specify a `username`:`password` 161 combination when the REST API is behind a Basic Auth proxy. 162 163 164 .. literalinclude:: output/sawtooth_block_show_usage.out 165 :language: console 166 167 sawtooth identity 168 ================= 169 170 Sawtooth supports an identity system that provides an extensible role- 171 and policy-based system for defining permissions in a way which can be 172 used by other pieces of the architecture. This includes the existing 173 permissioning components for transactor key and validator key; in the 174 future, this feature may also be used by transaction family 175 implementations. The ``sawtooth identity`` subcommands can be used to 176 view the current roles and policy set in state, create new roles, and 177 new policies. 178 179 Note that only the public keys stored in the setting 180 sawtooth.identity.allowed_keys are allowed to submit identity 181 transactions. Use the ``sawset`` commands to change this 182 setting. 183 184 185 .. literalinclude:: output/sawtooth_identity_usage.out 186 :language: console 187 188 sawtooth identity policy 189 ======================== 190 191 The ``sawtooth identity policy`` subcommands are used to display the 192 current policies stored in state and to create new policies. 193 194 .. literalinclude:: output/sawtooth_identity_policy_usage.out 195 :language: console 196 197 sawtooth identity policy create 198 =============================== 199 200 The ``sawtooth identity policy create`` subcommand creates a new 201 policy that can then be set to a role. The policy should contain at 202 least one “rule” (``PERMIT_KEY`` or ``DENY_KEY``). Note that all 203 policies have an assumed last rule to deny all. This subcommand can 204 also be used to change the policy that is already set to a role 205 without having to also reset the role. 206 207 .. literalinclude:: output/sawtooth_identity_policy_create_usage.out 208 :language: console 209 210 sawtooth identity policy list 211 ============================= 212 213 The ``sawtooth identity policy list`` subcommand lists the policies 214 that are currently set in state. This list can be used to figure out 215 which policy name should be set for a new role. 216 217 .. literalinclude:: output/sawtooth_identity_policy_list_usage.out 218 :language: console 219 220 sawtooth identity role 221 ====================== 222 223 The ``sawtooth identity role`` subcommands are used to list the 224 current roles stored in state and to create new roles. 225 226 .. literalinclude:: output/sawtooth_identity_role_usage.out 227 :language: console 228 229 sawtooth identity role create 230 ============================= 231 232 The ``sawtooth identity role create`` subcommand creates a new role 233 that can be used to enforce permissions. The policy argument 234 identifies the policy that the role is restricted to. This policy must 235 already exist and be stored in state. Use ``sawtooth identity policy 236 list`` to display the existing policies. The role name should 237 reference an action that can be taken on the network. For example, the 238 role named ``transactor.transaction_signer`` controls who is allowed 239 to sign transactions. 240 241 .. literalinclude:: output/sawtooth_identity_role_create_usage.out 242 :language: console 243 244 sawtooth identity role list 245 =========================== 246 247 The ``sawtooth identity role list`` subcommand displays the roles that 248 are currently set in state. This list can be used to determine which 249 permissions are being enforced on the network. The output includes 250 which policy the roles are set to. 251 252 By default, this information is displayed as a white-space delimited 253 table intended for display, but other plain-text formats (CSV, JSON, 254 and YAML) are available and can be piped into a file for further 255 processing. 256 257 .. literalinclude:: output/sawtooth_identity_role_list_usage.out 258 :language: console 259 260 sawtooth keygen 261 =============== 262 263 The ``sawtooth keygen`` subcommand generates a private key file and a public key 264 file so that users can sign Sawtooth transactions and batches. These 265 files are stored in the ``<key-dir>`` directory in ``<key_name>.priv`` 266 and ``<key_dir>/<key_name>.pub``. By default, ``<key_dir>`` is 267 ``~/.sawtooth`` and ``<key_name>`` is ``$USER``. 268 269 .. literalinclude:: output/sawtooth_keygen_usage.out 270 :language: console 271 272 sawtooth peer 273 ============= 274 275 The ``sawtooth peer`` subcommand displays the addresses of a specified 276 validator's peers. 277 278 .. literalinclude:: output/sawtooth_peer_usage.out 279 :language: console 280 281 sawtooth peer list 282 ================== 283 284 The ``sawtooth peer list`` subcommand displays the addresses of a 285 specified validator's peers. 286 287 This subcommand requires the URL of the REST API (default: 288 ``http://localhost:8008``), and can specify a `username`:`password` 289 combination when the REST API is behind a Basic Auth proxy. 290 291 .. literalinclude:: output/sawtooth_peer_list_usage.out 292 :language: console 293 294 sawtooth settings 295 ================= 296 297 The ``sawtooth settings`` subcommand displays the values of currently 298 active on-chain settings. 299 300 .. literalinclude:: output/sawtooth_settings_usage.out 301 :language: console 302 303 sawtooth settings list 304 ====================== 305 306 The ``sawtooth settings list`` subcommand displays the current keys 307 and values of on-chain settings. 308 309 .. literalinclude:: output/sawtooth_settings_list_usage.out 310 :language: console 311 312 sawtooth state 313 ============== 314 315 The ``sawtooth state`` subcommands display information about the 316 entries in the current blockchain state. 317 318 .. literalinclude:: output/sawtooth_state_usage.out 319 :language: console 320 321 sawtooth state list 322 =================== 323 324 The ``sawtooth state list`` subcommand queries the Sawtooth REST API 325 for a list of all state entries in the current blockchain state. This subcommand 326 returns the address of each entry, its size in bytes, and the 327 byte-encoded data it contains. It also returns the head block for 328 which this data is valid. 329 330 To control the state that is returned, use the ``subtree`` 331 argument to specify an address prefix as a filter or a block id to use 332 as the chain head. 333 334 By default, this information is displayed as a white-space delimited 335 table intended for display, but other plain-text formats (CSV, JSON, 336 and YAML) are available and can be piped into a file for further 337 processing. 338 339 This subcommand requires the URL of the REST API (default: 340 ``http://localhost:8008``), and can specify a `username`:`password` 341 combination when the REST API is behind a Basic Auth proxy. 342 343 .. literalinclude:: output/sawtooth_state_list_usage.out 344 :language: console 345 346 sawtooth state show 347 =================== 348 349 The ``sawtooth state show`` subcommand queries the Sawtooth REST API 350 for a specific state entry (address) in the current blockchain state. 351 It returns the data stored at this state address and the id of the 352 chain head for which this data is valid. This data is byte-encoded per 353 the logic of the transaction family that created it, and must be 354 decoded using that same logic. 355 356 This subcommand requires the URL of the REST API (default: 357 ``http://localhost:8008``), and can specify a `username`:`password` 358 combination when the REST API is behind a Basic Auth proxy. 359 360 By default, the peers are displayed as a CSV string, but other 361 plain-text formats (JSON, and YAML) are available and can be piped 362 into a file for further processing. 363 364 .. literalinclude:: output/sawtooth_state_show_usage.out 365 :language: console 366 367 sawtooth status 368 =============== 369 370 The ``sawtooth status`` subcommands display information related to a 371 validator's status. 372 373 .. literalinclude:: output/sawtooth_status_usage.out 374 :language: console 375 376 sawtooth status show 377 ==================== 378 379 The ``sawtooth status`` subcommand displays information related to a 380 validator's current status, including its public network endpoint and 381 its peers. 382 383 This subcommand requires the URL of the REST API (default: 384 ``http://localhost:8008``), and can specify a `username`:`password` 385 combination when the REST API is behind a Basic Auth proxy. 386 387 .. literalinclude:: output/sawtooth_status_show_usage.out 388 :language: console 389 390 sawtooth transaction 391 ==================== 392 393 The ``sawtooth transaction`` subcommands display information about the 394 transactions in the current blockchain. 395 396 .. literalinclude:: output/sawtooth_transaction_usage.out 397 :language: console 398 399 sawtooth transaction list 400 ========================= 401 402 The ``sawtooth transaction list`` subcommand queries the Sawtooth REST 403 API (default: ``http://localhost:8008``) for a list of transactions in 404 the current blockchain. It returns the id of each transaction, its 405 family and version, the size of its payload, and the data in the 406 payload itself. 407 408 By default, this information is displayed as a white-space delimited 409 table intended for display, but other plain-text formats (CSV, JSON, 410 and YAML) are available and can be piped into a file for further 411 processing. 412 413 .. literalinclude:: output/sawtooth_transaction_list_usage.out 414 :language: console 415 416 sawtooth transaction show 417 ========================= 418 419 The ``sawtooth transaction show`` subcommand queries the Sawtooth REST 420 API for a specific transaction in the current blockchain. It returns 421 complete information for this transaction in either YAML (default) or 422 JSON format. Use the ``--key`` option to narrow the 423 returned information to just the value of a single key, either from 424 the transaction or its header. 425 426 This subcommand requires the URL of the REST API (default: 427 ``http://localhost:8008``), and can specify a `username`:`password` 428 combination when the REST API is behind a Basic Auth proxy. 429 430 .. literalinclude:: output/sawtooth_transaction_show_usage.out 431 :language: console 432 433 .. Licensed under Creative Commons Attribution 4.0 International License 434 .. https://creativecommons.org/licenses/by/4.0/