Looking for BASH in the environment instead of invoking it directly
enables attacks where malware could escalate privileges by pointing BASH
to itself and tricking the user into entering a superuser password when
a user invokes our script, a familiar request the user may be expecting.
leap_testing dir is already part of package so don't need to mkdir or rmdir as it will be cleaned up appropriately.
However, continue to clean up dir potentially created directly by postinst
Can ignore failed directory deletion as they may be installing to location that has more than leap in it, for instance the ~/lib/python3/dist-packages, however if it is empty it is a safe assumption that it is in the location the install created it and can be removed as the inverse uninstall operation.
Adding additional commentary on cmake version based processing paths.
Added prerm script to cleanup symbolic links
Added EXCLUDE_FROM_ALL where necessary.
Move setting scripts to the package.cmake location suggested.
When additional command line arguments were added to performance_test_basic.py, some were inadvertently missed being passed from performance_test down to the performance_test_basic. Update the argument passing to match that in performance_test_basic.py.
If the targetTps is allowed to be 0, there can be a division by 0 error TpsTrxGensConfig because the numGenerators would be 0 and thus initialTpsPerGenerator would be division by 0. Fix this error through starting search floor at min 1 as well as capping the min to the floor.
CMake simplification.
Rename Queries to NodeosQueries.
Make transferFundsCmdArr conventionally accessible.
Rewrite some ancient C-style code to something more Pythonic.
Make appropriate use of sys.executable.
Add long form for help message.
Make sure launch_transaction_generators is added to the module.
Remove executable bits from scripts internal to the module.
Newer versions of Python, e.g. 3.11 require use of default_factory in dataclasses.
Newer versions of python/numpy no longer require np predicate before float, and can use float directly.
Additional work to clean up argument handling in trx generator main.
Drop a couple helper functions that we not needed.
Don't pass arguments into member functions that could simple access member variables.
Default to using cluster boostrap rather than shell script.
Tolerate dots in integration test names.
Relocate urllib support to queries.py, highest inheritance hierarchy
level it is used.
Miscellaneous code cleanup.
To enable heterogenous clusters:
- Self-configure Node version per node.
- Activate protocol features supported by lowest version node.
Boost authors, in their infinite wisdom, have written different default
resolver flags across overloads which take the same parameters at
different layers in the API.
Update user data transaction specification to support multiple actions and automatically generating an account namer per transaction to substitute into defined actions using the 'ACCT_PER_TRX' key word.
Removed arguments for action data pieces that have been moved into the larger transaction spec in the json files.
Added/Updated tests to exercise the new feature.
Add support for actionAuthAcct and actionAuthPrivKey for more explicit control when specifying transaction directly.
Add actionAuthAcct to json transaction description
Add trx generator id to allow differentiation of trx generators for use in create accounts.
Factored out set_transaction_headers into own helper function.
Write and read topology file in nodeosLogPath.
Convert nodeosLogPath to pathlib.
Implement support for --down argument.
Add minor additional debugging output to Node.
Refactor - move launchTrxGenerators from Node to Cluster where it fits better.
Add waitForTrxGeneratorsSpinup function which allows tests to wait for initial trx from each generator to appear in a block. This allows the tests to sync on the trx generators spinning up and knowing that trxs are flowing before proceeding with tests.
Update tests that used launchTrxGenerators for the refactor and to use the waitForTrxGeneratorsSpinup function.
trx_generator now logs first transaction it is preparing to send right before sending it to allow synchronization by tests without influencing its generation rate since it occurs prior only on initil trx and prior to initial trx send.
Factor out common trx generator launch setup and launch capabilities into Node.py for tests to utilize.
Move launch_transaction_generators.py into the TestHarness module. This made sense and also helped alleviate circular dependencies between modules.
Replace prev argument --user-trx-data with --user-trx-data-file.
Read user trx data in from file and use that directly in lieu of UserTrxData.
Update tests to exercise this path with sample userTrxData.json file.
Update report construction to support Paths.
Update performance_test_basic to support user specified transaction data through the use of the --user-trx-data command argument and the UserTrxData class. Now supports creation of named accounts for use in user defined transactions.
Cluster supports populating wallet with named accounts.
Renamed command line argument for making use of user provided trx data to --user-trx-data.
Transaction Geneators Launcher adds support for setting peer endpoint and port in trx generator.
Cluster adds p2pBasePort and means to calculate a given node's p2p listen port from node id.
Update tests using trx generator to specify peer endpoint and port to send trxs to.
Create python module for performance_tests to gain access to launch_transaction_generators utilities.
Update trx_generator and trx_provider to allow stopping generation on failure of transaction to send.
Add functionality to transaction generator to take input of abi from file, transaction action type, and action data from a string or file json description and generate transactions matching that description.
Rename handler_account to contract_owner_account for more accurate description.
Add integration test exercising the new functionality that builds transactions from abi, action type and action data. Makes use of the performance_test_basic with new argument '--exercise-trx-specification', but generates the transfer transactions from the abi, action name and action description in the test.
Added unit test to exercise the new trx_generator constructor.
Write bios_boot.sh script from Python launcher for the time being.
Relocate Python libc wrapper into TestHarness from tests.
Use unshare in Cluster instead of launcher.py.
Add --privileged flag to Github test container configuration.
BasePluginArgs provides generic implementations of __str__ and supportedNodeosArgs functions for use in each *PluginArgs classes.
Update generation script to no longer generate base class functions, but to inherit from base class.
Each *PluginArgs dataclass captures the command line argument and default for each option as specificed in nodeos.
New test validate_nodeos_plugin_args uses nodeos's --help command to parse out each plugin's available options and defaults to validate current status vs. the *PluginArgs classes. Any addition, removal, update will cause a test failure with note of what has changed. This will allow easy maintenance going forward.
The payload object can be extremely long when printing out during verbose logging. Rarely is the entire response needed for debugging. However, the code is often useful when something goes wrong. Reverse the order of code and payload so that, when trunctating printed responsed, the return code is always available. Truncate the response to 1024 characters.
This will greatly reduce work to bubble up arguments between scripts/modules. Also brings clarity and grouping of arguments by use with group titles and descriptions.
Test Helper arguments can now be bubbled up to user scripts via direct access to the ArgumentParser. Performance Test Basic makes use of Test Helper arguments. Perfomance Test makes use of both Performance Test Basic and Test Helper arguments as well.
Each plugin's option determines whether to calculate number of worker threads to use in the thread pool with options of: 'none', 'lmax', or 'full'. In 'none' mode, the default, no calculation will be attempted and default configured thread count will be used. In 'lmax' mode, thread count will incrementally be tested until the performance rate ceases to increase with the addition of subsequent threads. In 'full' mode thread count will incrementally be tested from 2..num logical processors, recording each performance and choosing the local max performance (same value as would be discovered in 'lmax' mode). Useful for graphing the full performance impact of each available thread.
Added log directory to collect results of thread optimization calculations.
Added option to opt out of running the tps test.
Updated README for new options and to show the updates to the result reports.
Using PtbConfig and LoggingConfig objects simplifies test initializer params and encapsulates related config items into an object describing their use. It also allows easy reporting of test configuration in test report and will allow reporting to come for free if additional config arguments are added.
Some renaming for efficiency and clarity.
Removing --resource-monitor-not-shutdown-on-threshold-exceeded in Cluster.py to allow resmon to shutdown as expected. Shouldn't default to disabling this. Also allows for Cluster.py to continue to be able to support older versions of nodeos for perf harness testing.
Trx generator can fail to keep up with configured tps generation rate. Detect that failure case and report it as test failure.
Move transaction recvd and expected check to similar location and handling.
Rename launcherExitCodes to trxGenExitCodes for clarity.
If providing disable-subjective-api-billing, should also provide disable-subjective-p2p-billing, otherwise simply add the disable-subjective-billing option which covers both. Opt to use the overarchign argument for now.
Leverage extraNodeosArgs configuration argument to support performance tuning of last block and cpu effort percentages, last block and produce time offsets, and signature cpu billable percent.
Default these performance tuning options for single producer node topology where production window will not pass to another producer node.
Update documentation for new features.
This pushes the calculations for number of generators required to hit overall target tps and the per-generator target tps to balance tps generation across all launched generators into one location to be referenced by others instead of needing to reproduce the calculations in multiple locations.
Move capturing of low level log artifacts until after cluster has shutdown to guarantee it is not longer needing the logs for its clean shutdown. Remove --keep-logs argument access and control it internally based on --del-perf-logs so that TestHelper and Cluster can continue to function normally with their arguments during shutdown and performance tests can still capture logs if necessary. Update documentation.
Update command line arguments to reflect the default capture of reports and, if choosing to not capture use the --del-report style arguments.
Update documentation to reflect argument changes and changes to log directory structure.
Test logs in etc and var are overwritten with each subsequent run of the test if left in place, thus move them out to test logs directories for later debugging use.
By default these logs will be captured unless explicitly disabled with --del-perf-logs argument.
Revise graphviz labels for utility and readability.
Fix off-by-one error in star topology and add missing loop increment.
Prevent self-peers in star topology.
No longer overload the --keep-logs argument.
Allows performance harness tests to default behavior to collecting and saving log files unless explicitly directly to delete logs.
In the general case, where --max-tps-to-test has been set well above achievable, this change adds one --test-iteration-duration-sec of time to the overarching test. In the case where it is successful it could save many cycles of time. It also puts one data point in the results summary that is basically an optimistic execution showing at potential overload what the avg tps looks like.
This avoids a problem where the long running test max is outside the window previously dictated for binary search and incorrectly reporting LongRunningMaxTpsAchieved = 0. Long Running max TPS should always be <= short running max tps, thus linearly decrementing search works well for this case.
This allows minimal initial support for dynamic configuration of the cluster via -p and -n arguments
Always guarantee one validation node is present by keeping _totalNodes always at least 1 greater than pnodes.
When disabling trace_api_plugin on producer nodes, can make use of specificExtraNodeosArgs to enable trace_api_plugin on specific nodes.
Default enable trace_api_plugin on bios node in eosio-launcher.
Allow Cluster createAccounts to specify which node is used to validate the transactions, as a node with trace_api_plugin enabled is required.
Updated report examples to include start and end times. Cleaned up some of the report formatting.
Updated timestamped log directories to be in UTC so that all timestamps are easier to trace back to log files and timestamps therein.
Make sure nodeDefinition name is initialized.
Use sensible default values that align with minimum network topology.
Default make_line to making a ring to match original behavior.
Remove extraneous line.
Previously, if not specifying --keep-logs, the reports would be deleted along with the logs. Now honor the --save-json and new --save-test-json parameters such that logs may all be deleted by json reports saved.
Introduced new --save-test-json argument to dictate whether to save json reports from each test scenario.
Update granularity of TPS values during search and max reporting to be nearest 100.
Update default min step size to 500.
Update binary search algorithm to keep floor and ceiling values at expected precision granularity (100).
Keep min step size the same for long running search scenario.
Performance Test runs a binary search of the TPS space using short runs to determine an effective TPS max. Then runs a series of longer test runs once it has zeroed in on a test range around the discovered max tps. Currently it determines success based on a very rudimentary success criteria looking at avg tps being close to target as well as all trxs sent being accounted for in blocks.
Update performance_test_basic.py to allow specification of a root directory for the logs to be stored in. Remove duplicate saveJsonReport in report in args. Move analyzedResultsAndReport before the shutdown sequence so that it will work if keep-logs is false, as it needs the logs to compute. Move test assert out of the test run itself so that when used as in import module the test doesn't assert and exit.
Updated scheduled transaction trace elapsed to include more of the execution time.
Renamed produced block log output conf to confirmed to match received block log output.
This was necessary as a first step to being able to use this functionality as an import module for an orchestrator to run multiple instances of PerformanceTestBasic with different tps configurations.
Some rework to how args are handled in the report. When run as an import module, command line args won't be the same or available. Get args/config info from how the PerformanceTestBasic was configured instead.
Created TestHelperConfig and ClusterConfig objects to help simplify and separate concerns for all the parameters to the test.
Move dataclasses and log scraping out of performance_test_basic.py into log_reader.py
Update read_log_data.py to properly calc trx latency as well as fix its ability to create the report from logs.
Update blkData to also use @property decorator
Write intermediate block data and trx data to log files to support read_log_data.py
Provide better log directory structure, setup and cleanup, and keep-logs support.
Move --num-blocks-to-prune into a CL argument to the script.
Fix timestamp for older versions of Python by not using fromisoformat and using strptime instead
Merge remote-tracking branch 'origin/release/3.1' into docs-openapi-trace_api-from-3.1-commit-to-main
- single file plugins/trace_api_plugin/trace_api.swagger.yaml
- shorted description refered back to developer docs
- allow return types for get_blocks any of BlockTraceV0, BlockTraceV1, BlockTraceV2
- BlockTraceV2 can return either Transaction Type V1 or Transaction Type V2
- allow return types for get_transaction_trace any of TransactionTraceV0, TransactionTraceV1, TransactionTraceV2
- shorted description refered back to developer docs
- allow return types for get_blocks any of BlockTraceV0, BlockTraceV1, BlockTraceV2
- BlockTraceV2 can return either Transaction Type V1 or Transaction Type V2
- allow return types for get_transaction_trace any of TransactionTraceV0, TransactionTraceV1, TransactionTraceV2
* Support MDX parsing
* Replace github references to EOS Network Foundation
* Replace references to old documentation portal
* Fix broken links
Markdown files under `docs` and under `tutorial`
The developer documentation portal is powered by markdown files. These files are parsed to create a nice looking web site. We use MDX as the parsing engine. MDX requires all html tags are closed. We went through all the files removing unneeded '<hr>' tags, enclosing angle brackets in quotes, and closing img tags.
Many times we found documentation pointing to old repositories that had not been updated in years. We updated the links and pointed to repositories that are better maintained.
We made sure links to the documentation portal did not leak back to older, previous versions.
We found relative links that no longer existed. We made sure to point the links to best location. Sometimes the links broke because were missing a key file extension. We made sure to add back the file extenstion.
**Note:** This is essentially a no-op; however summarizing here for anyone following the commit history. Glossary and Protocol Guides were added and removed during the course of development. We had added a Glossary and Protocol Guides , and we decided to utilize the welcome repository as the source for both.
commit ba20420c42f2f8bbf3396102d3ac22261028af30
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 12:46:52 2022 -0700
Testsnets anchor link was not working rm it
commit d5de39dbbe250d2a9878c82de990c086c3b7b122
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 10:27:42 2022 -0700
adding missing .md ext
commit 9dbb885d2eb308e60a2db909c9aed7b5dcb4289a
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 10:24:49 2022 -0700
found another eos.io reference to replace
commit 6a10c44b5863552c85c283db5b6d24e84b84f2cf
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 08:47:02 2022 -0700
moved away from eos testnet
commit 023c8e50724b766b0b9c8ce859d106101bc90fc8
Merge: 9d486ab51 6514a7d63
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 08:33:00 2022 -0700
Merge remote-tracking branch 'origin/main' into documentation-fixes
Fixing docs by removing eosio references, need resync with main to catch merge issues early
commit 9d486ab51aa399a4e5c7a038c19531071a88e900
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Aug 2 08:19:36 2022 -0700
updated protocol-guides links to include number
commit 907d9e2af8796087ba830f10f53df0063d0a621d
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Fri Jul 29 16:23:41 2022 -0700
removed general_info replaced by welcome repository markdown
commit 07efa3fb831ef2d57f68be0ef3aa21e28c346a80
Merge: 056239ccc d36ca7a52
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Fri Jul 29 07:10:24 2022 -0700
merging with upstream/main keeping up to date
commit 056239cccb5e3337b5598364190cd4dc9d16a281
Merge: b921bdf98 b378866ef
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 17:08:43 2022 -0700
Merge remote-tracking branch 'refs/remotes/origin/documentation-fixes' into documentation-fixes
Note pulled in "changes to lower bound description" 766C6164
Resolved Conflicts No Changes:
docs/general_info/glossary.md
docs/general_info/protocol-guides/consensus_protocol.md
docs/general_info/protocol-guides/network_peer_protocol.md
docs/general_info/protocol-guides/transactions_protocol.md
Changes to be committed:
modified: docs/general_info/protocol-guides/accounts_and_permissions.md
modified: libraries/chain/include/eosio/chain/webassembly/interface.hpp
commit b921bdf987c0206b6704968eaca3bc05c505d469
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 16:44:25 2022 -0700
removed eos.io from markdown
- Added docs/general_info/glossary.md
- Added docs/general_info/protocol-guides
- overview only for accounts_and_permissions.md
- overview only for transactions_protocol.md
- overview only for network_peer_protocol.md
- overview only for consensus_protocol.md
- Updated glossary.md to relative path (no more eos.io)
- Fixed links adding missing .md extenstion
- Updated protocol-guides to relative path (no more eos.io)
- Included BiosBoot tutorial on main document portal
- Fixed or removed broken links inside newly added glossary, guides, and tutorials
Note: squashed commits on branch down to single commit, less noise, easier to cherry-pick
commit b378866eff4be5cd3986c88a6d6ff39a802fee57
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 15:36:42 2022 -0700
adding back more missing .md extenstions, and simplying bios-boot-tutorial
commit 2f7c0e65cbf360ba13102c8a5341714c4ce1159d
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 15:14:16 2022 -0700
fixing more missing .md ext
commit 07b1f16962921acdd35d24c87e6a87378c7a10fc
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 15:03:06 2022 -0700
updated with .md ext
commit 002b01ddc81e67d09dba40fae9cc2303b4efed7b
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 14:29:33 2022 -0700
updated formate for glossary links to include .md
commit bf344ae16c76ca1109672b8e9cccc5a69527e3d3
Merge: 3bbb956b5 0cb196b7f
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 08:48:05 2022 -0700
merging main into documentation-fixes, after removing eso.io references adding glossary and guides
commit 3bbb956b524267c788dd9614011abeda1be96b93
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 08:47:12 2022 -0700
remove eos.io references, added glossary, guides
- Added new component schemas
- ERROR_DETAILS
- TRACE
- TRANSACTION_HEADER
- TRANSACTION_TRACE
- BLOCK_TRACE
- updated 4xx errors with shared ERROR_DETAILS component
- verification and updates for schema returned for get_block
- verifcation and updates for schema returned for get_transaction
Rename nodeos_log_scraping_test.py to log_reader_tests.py to house additional test coverage.
Cover block data log pruning and tps analysis in testing.
Fixes edge cases for 0 and 1 blocks in tps scoring algorithm.
To test performance limits, need to update genesis values that artificially impose performance limits on throughput. Of particular note: max_block_net_usage, max_block_cpu_usage, min_transaction_cpu_usage.
Update Cluster's defaults for --max-block-cpu-usage and --max-transaction-cpu-usage to only be applied if a genesis.json is not specified. Also updated to be in line with max allowed max-block-cpu-usage and typical default for max-transaction-cpu-usage
private key of k1 was randomly generated. It caused big swing in time with canonical
requirement. This commit makes the private key fixed and benchmarks both canonical
and non-canonical cases
Create a generic micro-benchmarking framework intended for any functions.
As the first application, alt_bn_128 adding/multiplying/pairing, sha3-256/keccak256
hashing, k1/r1/webauthn key signing/recovering, and modexp are benchmarked
Create some simple structs for managing action pairs, private keys, and transactions.
Factor out private keys into accessible objects for re-signing needs.
Before sending trxs on p2p provider interface update the trxs to be current and re-sign.
* Support MDX parsing
* Replace github references to EOS Network Foundation
* Replace references to old documentation portal
* Fix broken links
Markdown files under `docs` and under `tutorial`
The developer documentation portal is powered by markdown files. These files are parsed to create a nice looking web site. We use MDX as the parsing engine. MDX requires all html tags are closed. We went through all the files removing unneeded '<hr>' tags, enclosing angle brackets in quotes, and closing img tags.
Many times we found documentation pointing to old repositories that had not been updated in years. We updated the links and pointed to repositories that are better maintained.
We made sure links to the documentation portal did not leak back to older, previous versions.
We found relative links that no longer existed. We made sure to point the links to best location. Sometimes the links broke because were missing a key file extension. We made sure to add back the file extenstion.
**Note:** This is essentially a no-op; however summarizing here for anyone following the commit history. Glossary and Protocol Guides were added and removed during the course of development. We had added a Glossary and Protocol Guides , and we decided to utilize the welcome repository as the source for both.
commit ba20420c42f2f8bbf3396102d3ac22261028af30
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 12:46:52 2022 -0700
Testsnets anchor link was not working rm it
commit d5de39dbbe250d2a9878c82de990c086c3b7b122
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 10:27:42 2022 -0700
adding missing .md ext
commit 9dbb885d2eb308e60a2db909c9aed7b5dcb4289a
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 10:24:49 2022 -0700
found another eos.io reference to replace
commit 6a10c44b5863552c85c283db5b6d24e84b84f2cf
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 08:47:02 2022 -0700
moved away from eos testnet
commit 023c8e50724b766b0b9c8ce859d106101bc90fc8
Merge: 9d486ab51 6514a7d63
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Thu Aug 4 08:33:00 2022 -0700
Merge remote-tracking branch 'origin/main' into documentation-fixes
Fixing docs by removing eosio references, need resync with main to catch merge issues early
commit 9d486ab51aa399a4e5c7a038c19531071a88e900
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Aug 2 08:19:36 2022 -0700
updated protocol-guides links to include number
commit 907d9e2af8796087ba830f10f53df0063d0a621d
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Fri Jul 29 16:23:41 2022 -0700
removed general_info replaced by welcome repository markdown
commit 07efa3fb831ef2d57f68be0ef3aa21e28c346a80
Merge: 056239ccc d36ca7a52
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Fri Jul 29 07:10:24 2022 -0700
merging with upstream/main keeping up to date
commit 056239cccb5e3337b5598364190cd4dc9d16a281
Merge: b921bdf98 b378866ef
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 17:08:43 2022 -0700
Merge remote-tracking branch 'refs/remotes/origin/documentation-fixes' into documentation-fixes
Note pulled in "changes to lower bound description" 766C6164
Resolved Conflicts No Changes:
docs/general_info/glossary.md
docs/general_info/protocol-guides/consensus_protocol.md
docs/general_info/protocol-guides/network_peer_protocol.md
docs/general_info/protocol-guides/transactions_protocol.md
Changes to be committed:
modified: docs/general_info/protocol-guides/accounts_and_permissions.md
modified: libraries/chain/include/eosio/chain/webassembly/interface.hpp
commit b921bdf987c0206b6704968eaca3bc05c505d469
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 16:44:25 2022 -0700
removed eos.io from markdown
- Added docs/general_info/glossary.md
- Added docs/general_info/protocol-guides
- overview only for accounts_and_permissions.md
- overview only for transactions_protocol.md
- overview only for network_peer_protocol.md
- overview only for consensus_protocol.md
- Updated glossary.md to relative path (no more eos.io)
- Fixed links adding missing .md extenstion
- Updated protocol-guides to relative path (no more eos.io)
- Included BiosBoot tutorial on main document portal
- Fixed or removed broken links inside newly added glossary, guides, and tutorials
Note: squashed commits on branch down to single commit, less noise, easier to cherry-pick
commit b378866eff4be5cd3986c88a6d6ff39a802fee57
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 15:36:42 2022 -0700
adding back more missing .md extenstions, and simplying bios-boot-tutorial
commit 2f7c0e65cbf360ba13102c8a5341714c4ce1159d
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 15:14:16 2022 -0700
fixing more missing .md ext
commit 07b1f16962921acdd35d24c87e6a87378c7a10fc
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 15:03:06 2022 -0700
updated with .md ext
commit 002b01ddc81e67d09dba40fae9cc2303b4efed7b
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 14:29:33 2022 -0700
updated formate for glossary links to include .md
commit bf344ae16c76ca1109672b8e9cccc5a69527e3d3
Merge: 3bbb956b5 0cb196b7f
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 08:48:05 2022 -0700
merging main into documentation-fixes, after removing eso.io references adding glossary and guides
commit 3bbb956b524267c788dd9614011abeda1be96b93
Author: Eric Passmore <eric.passmore@gmail.com>
Date: Tue Jul 26 08:47:12 2022 -0700
remove eos.io references, added glossary, guides
Additional clean up throughout.
Support dynamic number of passed in accounts to create actions and transactions between.
Remove start_generation as it really wasn't doing anythig any more.
Very rough first draft of a transaction generator to lay the basis for development. Much of this will be refactored or removed as responsibility is delegated to other pieces of the perf harness. As well as adding command line options as much is hard coded at this time.
Very rough first draft of a transaction generator to lay the basis for development. Much of this will be refactored or removed as responsibility is delegated to other pieces of the perf harness. As well as adding command line options as much is hard coded at this time.
getClientVersion now returns a version format as expected from cleos version client.
If fullVersion is enabled, cleos full version will be returned which includes commit version.
The query object has been deprecated since boost 1.66. Incidentally
resolves#5422 when using TCP on a system with only loopback configured.
The preferred boost API no longer defaults to the address_configured
flag.
if(child_process.spawnSync("docker",["run","--name","base","-v",`${process.cwd()}/build.tar.zst:/build.tar.zst`,"--workdir","/__w/leap/leap",container,"sh","-c","zstdcat /build.tar.zst | tar x"],{stdio:"inherit"}).status)
// the correct approach is by far "--show-only=json-v1" and then pluck out .tests[].name; but that doesn't work on U18's cmake 3.10 since it lacks json-v1 output
Leap is a C++ implementation of the [Antelope](https://github.com/AntelopeIO) protocol. It contains blockchain node software and supporting tools for developers and node operators.
Leap is blockchain node software and supporting tools that implements the [Antelope](https://github.com/AntelopeIO) protocol.
## Branches
The `main` branch is the development branch; do not use it for production. Refer to the [release page](https://github.com/AntelopeIO/leap/releases) for current information on releases, pre-releases, and obsolete releases, as well as the corresponding tags for those releases.
## Repo Organization
## Supported Operating Systems
We currently support the following operating systems.
- Ubuntu 22.04 Jammy
- Ubuntu 20.04 Focal
- Ubuntu 18.04 Bionic
`main` branch is the development branch: do not use this for production. Refer to the [release page](https://github.com/AntelopeIO/leap/releases) for current information on releases, pre-releases, and obsolete releases as well as the corresponding tags for those releases.
Other Unix derivatives such as macOS are tended to on a best-effort basis and may not be full featured. If you aren't using Ubuntu, please visit the "[Build Unsupported OS](./docs/00_install/01_build-from-source/00_build-unsupported-os.md)" page to explore your options.
## Software Installation
Visit the [release page](https://github.com/AntelopeIO/leap/releases) for Ubuntu binaries. This is the fastest way to get started with the software.
### Building From Source
Recent Ubuntu LTS releases are the only Linux distributions that we fully support. Other Linux distros and other POSIX operating systems (such as macOS) are tended to on a best-effort basis and may not be full featured. Notable requirements to build are:
* C++17 compiler and standard library
* boost 1.67+
* CMake 3.8+
* (for Linux only) LLVM 7 - 11 (newer versions do not work)
A few other common libraries are tools also required such as openssl 1.1+, libcurl, curl, libusb, GMP, Python 3, and zlib.
**A Warning On Parallel Compilation Jobs (`-j` flag)**: When building C/C++ software often the build is performed in parallel via a command such as `make -j $(nproc)` which uses the number of CPU cores as the number of compilation jobs to perform simultaneously. However, be aware that some compilation units (.cpp files) in Leap are extremely complex and will consume nearly 4GB of memory to compile. You may need to reduce the level of parallelization depending on the amount of memory on your build host. e.g. instead of `make -j $(nproc)` run `make -j2`. Failures due to memory exhaustion will typically but not always manifest as compiler crashes.
Generally we recommend performing what we refer to as a "pinned build" which ensures the compiler and boost version remain the same between builds of different Leap versions (Leap requires these versions remain the same otherwise its state needs to be repopulated from a portable snapshot).
#### Building Pinned Build Binary Packages
In the directory `<leap src>/scripts` you will find the two scripts `install_deps.sh` and `pinned_build.sh`. If you haven't installed build dependencies then run `install_deps.sh`. Then run `pinned_build.sh <dependencies directory> <leap build directory> <number of jobs>`.
The dependencies directory is where the script will pull the C++ dependencies that need to be built with the pinned compiler for building the pinned binaries for binary packaging.
The binary package will be produced in the Leap build directory that was supplied.
If you are running an unsupported Ubuntu derivative, such as Linux Mint, you can find the version of Ubuntu your distribution was based on by using this command:
```bash
cat /etc/upstream-release/lsb-release
```
apt-get update && apt-get install \
build-essential \
cmake \
curl \
git \
libboost-all-dev \
libcurl4-openssl-dev \
libgmp-dev \
libssl-dev \
libusb-1.0-0-dev \
llvm-11-dev \
pkg-config
Your best bet is to follow the instructions for your Ubuntu base, but we make no guarantees.
## Binary Installation
This is the fastest way to get started. From the [latest release](https://github.com/AntelopeIO/leap/releases/latest) page, download a binary for one of our [supported operating systems](#supported-operating-systems), or visit the [release tags](https://github.com/AntelopeIO/leap/releases) page to download a binary for a specific version of Leap.
Once you have a `*.deb` file downloaded for your version of Ubuntu, you can install it as follows:
```bash
sudo apt-get update
sudo apt-get install -y ~/Downloads/leap*.deb
```
and perform the build:
Your download path may vary. If you are in an Ubuntu docker container, omit `sudo` because you run as `root` by default.
Finally, verify Leap was installed correctly:
```bash
nodeos --full-version
```
You should see a [semantic version](https://semver.org) string followed by a `git` commit hash with no errors. For example:
```
v3.1.2-0b64f879e3ebe2e4df09d2e62f1fc164cc1125d1
```
## Build and Install from Source
You can also build and install Leap from source.
### Prerequisites
You will need to build on a [supported operating system](#supported-operating-systems).
Requirements to build:
- C++17 compiler and standard library
- boost 1.67+
- CMake 3.8+
- LLVM 7 - 11 - for Linux only
- newer versions do not work
- openssl 1.1+
- curl
- libcurl 7.40.0+
- git
- GMP
- Python 3
- python3-numpy
- zlib
### Step 1 - Clone
If you don't have the Leap repo cloned to your computer yet, [open a terminal](https://itsfoss.com/open-terminal-ubuntu) and navigate to the folder where you want to clone the Leap repository:
Both an HTTPS or SSH git clone will yield the same result - a folder named `leap` containing our source code. It doesn't matter which type you use.
Navigate into that folder:
```bash
cd leap
```
### Step 2 - Checkout Release Tag or Branch
Choose which [release](https://github.com/AntelopeIO/leap/releases) or [branch](#branches) you would like to build, then check it out. If you are not sure, use the [latest release](https://github.com/AntelopeIO/leap/releases/latest). For example, if you want to build release 3.1.2 then you would check it out using its tag, `v3.1.2`. In the example below, replace `v0.0.0` with your selected release tag accordingly:
```bash
git fetch --all --tags
git checkout v0.0.0
```
Once you are on the branch or release tag you want to build, make sure everything is up-to-date:
```bash
git pull
git submodule update --init --recursive
mkdir build
```
### Step 3 - Build
Select build instructions below for a [pinned build](#pinned-build) (preferred) or an [unpinned build](#unpinned-build).
> ℹ️ **Pinned vs. Unpinned Build** ℹ️
We have two types of builds for Leap: "pinned" and "unpinned." The only difference is that pinned builds use specific versions for some dependencies hand-picked by the Leap engineers - they are "pinned" to those versions. In contrast, unpinned builds use the default dependency versions available on the build system at the time. We recommend performing a "pinned" build to ensure the compiler and boost versions remain the same between builds of different Leap versions. Leap requires these versions to remain the same, otherwise its state might need to be recovered from a portable snapshot or the chain needs to be replayed.
> ⚠️ **A Warning On Parallel Compilation Jobs (`-j` flag)** ⚠️
When building C/C++ software, often the build is performed in parallel via a command such as `make -j "$(nproc)"` which uses all available CPU threads. However, be aware that some compilation units (`*.cpp` files) in Leap will consume nearly 4GB of memory. Failures due to memory exhaustion will typically, but not always, manifest as compiler crashes. Using all available CPU threads may also prevent you from doing other things on your computer during compilation. For these reasons, consider reducing this value.
> 🐋 **Docker and `sudo`** 🐋
If you are in an Ubuntu docker container, omit `sudo` from all commands because you run as `root` by default. Most other docker containers also exclude `sudo`, especially Debian-family containers. If your shell prompt is a hash tag (`#`), omit `sudo`.
#### Pinned Build
Make sure you are in the root of the `leap` repo, then run the `install_depts.sh` script to install dependencies:
```bash
sudo scripts/install_deps.sh
```
Next, run the pinned build script. You have to give it three arguments in the following order:
1. A temporary folder, for all dependencies that need to be built from source.
1. A build folder, where the binaries you need to install will be built to.
1. The number of jobs or CPU cores/threads to use (note the [jobs flag](#step-3---build) warning above).
> 🔒 You do not need to run this script with `sudo` or as root.
For example, the following command runs the `pinned_build.sh` script, specifies a `deps` and `build` folder in the root of the Leap repo for the first two arguments, then builds the packages using all of your computer's CPU threads:
```bash
scripts/pinned_build.sh deps build "$(nproc)"
```
Now you can optionally [test](#step-4---test) your build, or [install](#step-5---install) the `*.deb` binary packages, which will be in the root of your build directory.
#### Unpinned Build
The following instructions are valid for this branch. Other release branches may have different requirements, so ensure you follow the directions in the branch or release you intend to build. If you are in an Ubuntu docker container, omit `sudo` because you run as `root` by default.
After building you may remove the `$HOME/boost1.79` directory, or you may keep it around until next time building the software.
After building, you may remove the `~/boost1.79` directory or you may keep it around for your next build.
</details>
### Running Tests
Now you can optionally [test](#step-4---test) your build, or [install](#step-5---install) the `*.deb` binary packages, which will be in the root of your build directory.
When building from source it's recommended to run at least what we refer to as the "parallelizable tests". Not included by default in the "parallelizable tests" are the WASM spec tests which can add additional coverage and can also be run in parallel.
### Step 4 - Test
Leap supports the following test suites:
```
cd build
Test Suite | Test Type | [Test Size](https://testing.googleblog.com/2010/12/test-sizes.html) | Notes
---|:---:|:---:|---
[Parallelizable tests](#parallelizable-tests) | Unit tests | Small
[WASM spec tests](#wasm-spec-tests) | Unit tests | Small | Unit tests for our WASM runtime, each short but _very_ CPU-intensive
[Serial tests](#serial-tests) | Component/Integration | Medium
[Long-running tests](#long-running-tests) | Integration | Medium-to-Large | Tests which take an extraordinarily long amount of time to run
# "parallelizable tests": the minimum test set that should be run
ctest -j $(nproc) -LE _tests
When building from source, we recommended running at least the [parallelizable tests](#parallelizable-tests).
# Also consider running the WASM spec tests for more coverage
ctest -j $(nproc) -L wasm_spec_tests
#### Parallelizable Tests
This test suite consists of any test that does not require shared resources, such as file descriptors, specific folders, or ports, and can therefore be run concurrently in different threads without side effects (hence, easily parallelized). These are mostly unit tests and [small tests](https://testing.googleblog.com/2010/12/test-sizes.html) which complete in a short amount of time.
You can invoke them by running `ctest` from a terminal in your Leap build directory and specifying the following arguments:
```bash
ctest -j "$(nproc)" -LE _tests
```
Some other tests are available and recommended but be aware they can be sensitive to other software running on the same host and they may **SIGKILL** other nodeos instances running on the host.
```
cd build
#### WASM Spec Tests
The WASM spec tests verify that our WASM execution engine is compliant with the web assembly standard. These are very [small](https://testing.googleblog.com/2010/12/test-sizes.html), very fast unit tests. However, there are over a thousand of them so the suite can take a little time to run. These tests are extremely CPU-intensive.
# These tests can't run in parallel but are recommended.
You can invoke them by running `ctest` from a terminal in your Leap build directory and specifying the following arguments:
```bash
ctest -j "$(nproc)" -L wasm_spec_tests
```
We have observed severe performance issues when multiple virtual machines are running this test suite on the same physical host at the same time, for example in a CICD system. This can be resolved by disabling hyperthreading on the host.
#### Serial Tests
The serial test suite consists of [medium](https://testing.googleblog.com/2010/12/test-sizes.html) component or integration tests that use specific paths, ports, rely on process names, or similar, and cannot be run concurrently with other tests. Serial tests can be sensitive to other software running on the same host and they may `SIGKILL` other `nodeos` processes. These tests take a moderate amount of time to complete, but we recommend running them.
You can invoke them by running `ctest` from a terminal in your Leap build directory and specifying the following arguments:
```bash
ctest -L "nonparallelizable_tests"
```
# These tests can't runin parallel. They also take a long time to run.
#### Long-Running Tests
The long-running tests are [medium-to-large](https://testing.googleblog.com/2010/12/test-sizes.html) integration tests that rely on shared resources and take a very long time to run.
You can invoke them by running `ctest` from a terminal in your Leap build directory and specifying the following arguments:
```bash
ctest -L "long_running_tests"
```
### Step 5 - Install
Once you have [built](#step-3---build-the-source-code) Leap and [tested](#step-4---test) your build, you can install Leap on your system. Don't forget to omit `sudo` if you are running in a docker container.
We recommend installing the binary package you just built. Navigate to your Leap build directory in a terminal and run this command:
```bash
sudo apt-get update
sudo apt-get install -y ./leap[-_][0-9]*.deb
```
It is also possible to install using `make` instead:
| If you have previously installed EOSIO from source using shell scripts, you must first run the [Uninstall Script](01_build-from-source/01_shell-scripts/05_uninstall-eosio.md) before installing any prebuilt binaries on the same OS.
## Prebuilt Binaries
Prebuilt EOSIO software packages are available for the operating systems below. Find and follow the instructions for your OS:
where `version-string` is the EOSIO version that was installed.
Also, soft links for each EOSIO program (`nodeos`, `cleos`, `keosd`, etc.) will be created under `usr/bin` or `usr/local/bin` to allow them to be executed from any directory.
## Previous Versions
To install previous versions of the EOSIO prebuilt binaries:
1. Browse to https://github.com/EOSIO/eos/tags and select the actual version of the EOSIO software you need to install.
2. Scroll down past the `Release Notes` and download the package or archive that you need for your OS.
3. Follow the instructions on the first paragraph above to install the selected prebuilt binaries on the given OS.
content_title: Build Antelope from Source on Other Unix-based OS
---
**Please keep in mind that instructions for building from source on other unsupported operating systems provided here should be considered experimental and provided AS-IS on a best-effort basis and may not be fully featured.**
### Using DUNE
For the official multi-platform support try [Docker Utilities for Node Execution](https://github.com/AntelopeIO/DUNE) which runs in an ubuntu image via a docker container.
**A Warning On Parallel Compilation Jobs (`-j` flag)**: When building C/C++ software often the build is performed in parallel via a command such as `make -j $(nproc)` which uses the number of CPU cores as the number of compilation jobs to perform simultaneously. However, be aware that some compilation units (.cpp files) in mandel are extremely complex and will consume nearly 4GB of memory to compile. You may need to reduce the level of parallelization depending on the amount of memory on your build host. e.g. instead of `make -j $(nproc)` run `make -j2`. Failures due to memory exhaustion will typically but not always manifest as compiler crashes.
Generally we recommend performing what we refer to as a "pinned build" which ensures the compiler and boost version remain the same between builds of different mandel versions (mandel requires these versions remain the same otherwise its state needs to be repopulated from a portable snapshot).
When building from source it's recommended to run at least what we refer to as the "parallelizable tests". Not included by default in the "parallelizable tests" are the WASM spec tests which can add additional coverage and can also be run in parallel.
```
cd build
# "parallelizable tests": the minimum test set that should be run
ctest -j $(nproc) -LE _tests
# Also consider running the WASM spec tests for more coverage
ctest -j $(nproc) -L wasm_spec_tests
```
Some other tests are available and recommended but be aware they can be sensitive to other software running on the same host and they may **SIGKILL** other nodeos instances running on the host.
```
cd build
# These tests can't run in parallel but are recommended.
ctest -L "nonparallelizable_tests"
# These tests can't run in parallel. They also take a long time to run.
To download the EOSIO source code, clone the `eos` repo and its submodules. It is adviced to create a home `eosio` folder first and download all the EOSIO related software there:
If a repository is cloned without the `--recursive` flag, the submodules *must* be updated before starting the build process:
```sh
cd ~/eosio/eos
git submodule update --init --recursive
```
## Pull Changes
When pulling changes, especially after switching branches, the submodules *must* also be updated. This can be achieved with the `git submodule` command as above, or using `git pull` directly:
| The build script is one of various automated shell scripts provided in the EOSIO repository for building, installing, and optionally uninstalling the EOSIO software and its dependencies. They are available in the `eos/scripts` folder.
The build script first installs all dependencies and then builds EOSIO. The script supports these [Operating Systems](../../index.md#supported-operating-systems). To run it, first change to the `~/eosio/eos` folder, then launch the script:
```sh
cd ~/eosio/eos
./scripts/eosio_build.sh
```
The build process writes temporary content to the `eos/build` folder. After building, the program binaries can be found at `eos/build/programs`.
[[info | What's Next?]]
| [Installing EOSIO](03_install-eosio-binaries.md) is strongly recommended after building from source as it makes local development significantly more friendly.
For ease of contract development, content can be installed at the `/usr/local` folder using the `eosio_install.sh` script within the `eos/scripts` folder. Adequate permission is required to install on system folders:
```sh
cd ~/eosio/eos
./scripts/eosio_install.sh
```
## EOSIO manual install
In lieu of the `eosio_install.sh` script, you can install the EOSIO binaries directly by invoking `make install` within the `eos/build` folder. Again, adequate permission is required to install on system folders:
```sh
cd ~/eosio/eos/build
make install
```
[[info | What's Next?]]
| Configure and use [Nodeos](../../../01_nodeos/index.md), or optionally [Test the EOSIO binaries](04_test-eosio-binaries.md).
If you have previously built EOSIO from source and now wish to install the prebuilt binaries, or to build from source again, it is recommended to run the `eosio_uninstall.sh` script within the `eos/scripts` folder:
```sh
cd ~/eosio/eos
./scripts/eosio_uninstall.sh
```
[[info | Uninstall Dependencies]]
| The uninstall script will also prompt the user to uninstall EOSIO dependencies. This is recommended if installing prebuilt EOSIO binaries or building EOSIO for the first time.
[[info | Building EOSIO is for Advanced Developers]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](../../00_install-prebuilt-binaries.md) instead of building from source.
The EOSIO software requires specific software dependencies to build the EOSIO binaries. These dependencies can be built from source or installed from binaries directly. Dependencies can be pinned to a specific version release or unpinned to the current version, usually the latest one. The main EOSIO dependencies hosted outside the EOSIO repos are:
* Clang - the C++17 compliant compiler used by EOSIO
* CMake - the build system used by EOSIO
* Boost - the C++ Boost library used by EOSIO
* OpenSSL - the secure communications (and crypto) library
* LLVM - the LLVM compiler/toolchain infrastructure
Other dependencies are either inside the EOSIO repo, such as the `secp256k1` elliptic curve DSA library, or they are otherwise used for testing or housekeeping purposes, such as:
* automake, autoconf, autotools
* doxygen, graphviz
* python2, python3
* bzip2, zlib
* etc.
## Pinned Dependencies
To guarantee interoperability across different EOSIO software releases, developers may opt to reproduce the exact "pinned" dependency binaries used in-house. Block producers may want to install and run the EOSIO software built with these pinned dependencies for portability and stability reasons. Pinned dependencies are usually built from source.
## Unpinned Dependencies
Regular users or application developers may prefer installing unpinned versions of the EOSIO dependencies. These correspond to the latest or otherwise stable versions of the dependencies. The main advantage of unpinned dependencies is reduced installation times and perhaps better performance. Pinned dependencies are typically installed from binaries.
## Automatic Installation of Dependencies
EOSIO dependencies can be built or installed automatically from the [Build Script](../01_shell-scripts/02_build-eosio-binaries.md) when building EOSIO from source. To build the pinned dependencies, the optional `-P` parameter can be specified when invoking the script. Otherwise, the unpinned dependencies will be installed instead, with the exception of `boost` and `cmake` which are always pinned:
```sh
cd ~/eosio/eos
./scripts/eosio_build.sh [-P]
```
### Unupported Platforms
EOSIO dependencies can also be built and installed manually by reproducing the same commands invoked by the [Build Script](../01_shell-scripts/02_build-eosio-binaries.md). The actual commands can be generated from the script directly by exporting specific environment variables and CLI parameters to the script when invoked:
This section contains shell commands to manually download, build, install, test, and uninstall EOSIO and dependencies on Amazon Linux 2.
[[info | Building EOSIO is for Advanced Developers]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](../../../00_install-prebuilt-binaries.md) instead of building from source.
Select a task below, then copy/paste the shell commands to a Unix terminal to execute:
Thesecommandsinstall the EOSIO software dependencies. Make sure to [Download the EOSIO Repository](#download-eosio-repository) first and set the EOSIO directories.
```sh
# install dependencies
yum install -y which sudo procps-ng util-linux autoconf automake \
libtool make bzip2 bzip2-devel openssl-devel gmp-devel libstdc++ libcurl-devel \
This command installs the EOSIO software on the specified OS. Make sure to [Build EOSIO](#build-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&& make install
```
## Test EOSIO
These commands validate the EOSIO software installation on the specified OS. This task is optional but recommended. Make sure to [Install EOSIO](#install-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&& make test
```
## Uninstall EOSIO
These commands uninstall the EOSIO software from the specified OS.
This section contains shell commands to manually download, build, install, test, and uninstall EOSIO and dependencies on Centos 7.7.
[[info | Building EOSIO is for Advanced Developers]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](../../../00_install-prebuilt-binaries.md) instead of building from source.
Select a task below, then copy/paste the shell commands to a Unix terminal to execute:
Thesecommandsinstall the EOSIO software dependencies. Make sure to [Download the EOSIO Repository](#download-eosio-repository) first and set the EOSIO directories.
This command installs the EOSIO software on the specified OS. Make sure to [Build EOSIO](#build-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&& make install
```
## Test EOSIO
These commands validate the EOSIO software installation on the specified OS. This task is optional but recommended. Make sure to [Install EOSIO](#install-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&&source /opt/rh/rh-python36/enable && make test
```
## Uninstall EOSIO
These commands uninstall the EOSIO software from the specified OS.
This section contains shell commands to manually download, build, install, test, and uninstall EOSIO and dependencies on MacOS 10.14.
[[info | Building EOSIO is for Advanced Developers]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](../../../00_install-prebuilt-binaries.md) instead of building from source.
Select a task below, then copy/paste the shell commands to a Unix terminal to execute:
Thesecommandsinstall the EOSIO software dependencies. Make sure to [Download the EOSIO Repository](#download-eosio-repository) first and set the EOSIO directories.
cd$EOSIO_BUILD_LOCATION&& make -j$(getconf _NPROCESSORS_ONLN)
```
## Install EOSIO
This command installs the EOSIO software on the specified OS. Make sure to [Build EOSIO](#build-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&& make install
```
## Test EOSIO
These commands validate the EOSIO software installation on the specified OS. This task is optional but recommended. Make sure to [Install EOSIO](#install-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&& make test
```
## Uninstall EOSIO
These commands uninstall the EOSIO software from the specified OS.
This section contains shell commands to manually download, build, install, test, and uninstall EOSIO and dependencies on Ubuntu 18.04.
[[info | Building EOSIO is for Advanced Developers]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](../../../00_install-prebuilt-binaries.md) instead of building from source.
Select a task below, then copy/paste the shell commands to a Unix terminal to execute:
Thesecommandsinstall the EOSIO software dependencies. Make sure to [Download the EOSIO Repository](#download-eosio-repository) first and set the EOSIO directories.
This command installs the EOSIO software on the specified OS. Make sure to [Build EOSIO](#build-eosio) first.
```sh
cd$EOSIO_BUILD_LOCATION&& make install
```
## Test EOSIO
These commands validate the EOSIO software installation on the specified OS. Make sure to [Install EOSIO](#install-eosio) first. (**Note**: This task is optional but recommended.)
```sh
cd$EOSIO_BUILD_LOCATION&& make test
```
## Uninstall EOSIO
These commands uninstall the EOSIO software from the specified OS.
[[info | Manual Builds are for Advanced Developers]]
| These manual instructions are intended for advanced developers. The [Shell Scripts](../01_shell-scripts/index.md) should be the preferred method to build EOSIO from source. If the script fails or your platform is not supported, continue with the instructions below.
## EOSIO Dependencies
When performing a manual build, it is necessary to install specific software packages that the EOSIO software depends on. To learn more about these dependencies, visit the [EOSIO Software Dependencies](00_eosio-dependencies.md) section.
## Platforms
Shell commands are available to manually download, build, install, test, and uninstall the EOSIO software and dependencies for these [platforms](03_platforms/index.md).
## Out-of-source Builds
While building dependencies and EOSIO binaries, out-of-source builds are also supported. Refer to the `cmake` help for more information.
## Other Compilers
To override `clang`'s default compiler toolchain, add these flags to the `cmake` command within the above instructions:
[[info | Building EOSIO is for Advanced Developers]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](../00_install-prebuilt-binaries.md) instead of building from source.
The shell scripts previously recommended for building the software have been removed in favor of a build process entirely driven by CMake. Those wishing to build from source are now responsible for installing the necessary dependencies. The list of dependencies and the recommended build procedure are in the [`README.md`](https://github.com/AntelopeIO/leap/blob/main/README.md) file. Instructions are also included for efficiently running the tests.
EOSIO can be built on several platforms using different build methods. Advanced users may opt to build EOSIO using our shell scripts. Node operators or block producers who wish to deploy a public node, may prefer our manual build instructions.
### Using DUNE
As an alternative to building from source, try [Docker Utilities for Node Execution](https://github.com/AntelopeIO/DUNE) for the easiest way to get started and for multi-platform support.
* [Shell Scripts](01_shell-scripts/index.md) - Suitable for the majority of developers, these scripts build on Mac OS and many flavors of Linux.
* [Manual Build](02_manual-build/index.md) - Suitable for those platforms that may be hostile to the shell scripts or for operators who need more control over their builds.
### Building From Source
You canalso build and install Leap from source. Instructions for that currently live [here](https://github.com/AntelopeIO/leap/blob/main/README.md#build-and-install-from-source).
[[info | EOSIO Installation Recommended]]
| After building EOSIO successfully, it is highly recommended to install the EOSIO binaries from their default build directory. This copies the EOSIO binaries to a central location, such as `/usr/local/bin`, or `~/eosio/x.y/bin`, where `x.y` is the EOSIO release version.
#### Building Pinned Build Binary Packages
The pinned buildinstructions have moved [here](https://github.com/AntelopeIO/leap/blob/main/README.md#pinned-build). You may want to look at the [prerequisites](https://github.com/AntelopeIO/leap/blob/main/README.md#prerequisites) and our warning on parallelization using the `-j` jobs flag [here](https://github.com/AntelopeIO/leap/blob/main/README.md#step-3---build) before you build.
#### Manual (non "pinned") Build Instructions
The unpinned build instructions have moved [here](https://github.com/AntelopeIO/leap/blob/main/README.md#unpinned-build). You may want to look at the [prerequisites](https://github.com/AntelopeIO/leap/blob/main/README.md#prerequisites) and our warning on parallelization using the `-j` jobs flag [here](https://github.com/AntelopeIO/leap/blob/main/README.md#step-3---build) before you build.
### Running Tests
Documentation on available test suites and how to run them has moved [here](https://github.com/AntelopeIO/leap/blob/main/README.md#test).
* [Build EOSIO from Source](01_build-from-source/index.md)
[[info]]
| If you are new to EOSIO, it is recommended that you install the [EOSIO Prebuilt Binaries](00_install-prebuilt-binaries.md), then proceed to the [Getting Started](https://developers.eos.io/eosio-home/docs/) section of the [EOSIO Developer Portal](https://developers.eos.io/). If you are an advanced developer, a block producer, or no binaries are available for your platform, you may need to [Build EOSIO from source](01_build-from-source/index.md) instead.
* [Build Antelope from Source](01_build-from-source/index.md)
## Supported Operating Systems
EOSIO currently supports the following operating systems:
Antelope currently supports the following operating systems:
1.Amazon Linux 2
2.CentOS 7
3. Ubuntu 16.04
4. Ubuntu 18.04
5. MacOS 10.14 (Mojave)
1.Ubuntu 22.04 Jammy
2.Ubuntu 20.04 Focal
3. Ubuntu 18.04 Bionic
[[info | Note]]
| It may be possible to install EOSIO on other Unix-based operating systems. This is not officially supported, though.
| It may be possible to build and install Antelope on other Unix-based operating systems. We gathered helpful information on the following page but please keep in mind that it is experimental and not officially supported.
* [Build Antelope on Other Unix-based Systems](01_build-from-source/00_build-unsupported-os.md)
## Docker Utilities for Node Execution (D.U.N.E.)
If you are using different operating system or prefer not to build Antelope from source you can try our Docker - based set of utilities called DUNE that can get you started with exploring Antelope and doing contract development pretty much instantly
* [Docker Utilities for Node Execution (D.U.N.E.)](https://github.com/AntelopeIO/DUNE)
This section describes how to set up a producing node within the EOSIO network. A producing node, as its name implies, is a node that is configured to produce blocks in an `EOSIO` based blockchain. This functionality if provided through the `producer_plugin` as well as other [Nodeos Plugins](../../03_plugins/index.md).
This section describes how to set up a producing node within the Antelope network. A producing node, as its name implies, is a node that is configured to produce blocks in an `Antelope` based blockchain. This functionality if provided through the `producer_plugin` as well as other [Nodeos Plugins](../../03_plugins/index.md).
## Before you begin
* [Install the EOSIO software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path. If you built EOSIO using shell scripts, make sure to run the [Install Script](../../../00_install/01_build-from-source/01_shell-scripts/03_install-eosio-binaries.md).
* [Install the Antelope software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path.
[//]: # ( THIS IS A COMMENT LINK BELOW IS BROKEN )
[//]: # ( If you built Antelope using shell scripts, make sure to run the Install Script ../../../00_install/01_build-from-source/01_shell-scripts/03_install-antelope-binaries.md )
* Know how to pass [Nodeos options](../../02_usage/00_nodeos-options.md) to enable or disable functionality.
## Steps
@@ -46,11 +50,11 @@ producer-name = youraccount
### 3. Set the Producer's signature-provider
You will need to set the private key for your producer. The public key should have an authority for the producer account defined above.
You will need to set the private key for your producer. The public key should have an authority for the producer account defined above.
`signature-provider` is defined with a 3-field tuple:
*`public-key` - A valid EOSIO public key in form of a string.
*`provider-spec` - It's a string formatted like <provider-type>:<data>
*`public-key` - A valid Antelope public key in form of a string.
*`provider-spec` - It's a string formatted like `<provider-type>:<data>`
This section describes how to set up a non-producing node within the EOSIO network. A non-producing node is a node that is not configured to produce blocks, instead it is connected and synchronized with other peers from an `EOSIO` based blockchain, exposing one or more services publicly or privately by enabling one or more [Nodeos Plugins](../../03_plugins/index.md), except the `producer_plugin`.
This section describes how to set up a non-producing node within the Antelope network. A non-producing node is a node that is not configured to produce blocks, instead it is connected and synchronized with other peers from an `Antelope` based blockchain, exposing one or more services publicly or privately by enabling one or more [Nodeos Plugins](../../03_plugins/index.md), except the `producer_plugin`.
## Before you begin
* [Install the EOSIO software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path. If you built EOSIO using shell scripts, make sure to run the [Install Script](../../../00_install/01_build-from-source/01_shell-scripts/03_install-eosio-binaries.md).
* [Install the Antelope software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path.
[//]: # ( THIS IS A COMMENT NEXT LINK CONTAINS A BROKEN LINK )
[//]: # ( If you built Antelope using shell scripts, make sure to run the Install Script ../../../00_install/01_build-from-source/01_shell-scripts/03_install-antelope-binaries.md )
* Know how to pass [Nodeos options](../../02_usage/00_nodeos-options.md) to enable or disable functionality.
## Steps
To setup a non-producing node is simple.
To setup a non-producing node is simple.
1. [Set Peers](#1-set-peers)
2. [Enable one or more available plugins](#2-enable-one-or-more-available-plugins)
Each available plugin is listed and detailed in the [Nodeos Plugins](../../03_plugins/index.md) section. When `nodeos` starts, it will expose the functionality provided by the enabled plugins it was started with. For example, if you start `nodeos` with [`state_history_plugin`](../../03_plugins/state_history_plugin/index.md) enabled, you will have a non-producing node that offers full blockchain history. If you start `nodeos` with [`http_plugin`](../../03_plugins/http_plugin/index.md) enabled, you will have a non-producing node which exposes the EOSIO RPC API. Therefore, you can extend the basic functionality provided by a non-producing node by enabling any number of existing plugins on top of it. Another aspect to consider is that some plugins have dependencies to other plugins. Therefore, you need to satisfy all dependencies for a plugin in order to enable it.
Each available plugin is listed and detailed in the [Nodeos Plugins](../../03_plugins/index.md) section. When `nodeos` starts, it will expose the functionality provided by the enabled plugins it was started with. For example, if you start `nodeos` with [`state_history_plugin`](../../03_plugins/state_history_plugin/index.md) enabled, you will have a non-producing node that offers full blockchain history. If you start `nodeos` with [`http_plugin`](../../03_plugins/http_plugin/index.md) enabled, you will have a non-producing node which exposes the Antelope RPC API. Therefore, you can extend the basic functionality provided by a non-producing node by enabling any number of existing plugins on top of it. Another aspect to consider is that some plugins have dependencies to other plugins. Therefore, you need to satisfy all dependencies for a plugin in order to enable it.
@@ -12,8 +12,12 @@ This section describes how to set up a single-node blockchain configuration runn
## Before you begin
* [Install the EOSIO software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path. If you built EOSIO using shell scripts, make sure to run the [Install Script](../../../00_install/01_build-from-source/01_shell-scripts/03_install-eosio-binaries.md).
* [Install the Antelope software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path.
[//]: # (THIS IS A COMMENT, NEXT LINK HAS BROKEN LINK)
[//]: # (If you built Antelope using shell scripts, make sure to run the Install Script ../../../00_install/01_build-from-source/01_shell-scripts/03_install-antelope-binaries.md .)
* Know how to pass [Nodeos options](../../02_usage/00_nodeos-options.md) to enable or disable functionality.
## Steps
@@ -87,7 +91,7 @@ The more advanced user will likely have need to modify the configuration. `node
* Linux: `~/.local/share/eosio/nodeos/config`
The build seeds this folder with a default `genesis.json` file. A configuration folder can be specified using the `--config-dir` command line argument to `nodeos`. If you use this option, you will need to manually copy a `genesis.json` file to your config folder.
`nodeos` will need a properly configured `config.ini` file in order to do meaningful work. On startup, `nodeos` looks in the config folder for `config.ini`. If one is not found, a default `config.ini` file is created. If you do not already have a `config.ini` file ready to use, run `nodeos` and then close it immediately with <kbd>Ctrl-C</kbd>. A default configuration (`config.ini`) will have been created in the config folder. Edit the `config.ini` file, adding/updating the following settings to the defaults already in place:
```console
@@ -115,7 +119,7 @@ nodeos
* Mac OS: `~/Library/Application\ Support/eosio/nodeos/data`
* Linux: `~/.local/share/eosio/nodeos/data`
A data folder can be specified using the `--data-dir` command line argument to `nodeos`.
@@ -10,8 +10,8 @@ This section describes how to set up a multi-node blockchain configuration runni
## Before you begin
* [Install the EOSIO software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path. If you built EOSIO using shell scripts, make sure to run the [Install Script](../../../00_install/01_build-from-source/01_shell-scripts/03_install-eosio-binaries.md).
* [Install the Antelope software](../../../00_install/index.md) before starting this section.
* It is assumed that `nodeos`, `cleos`, and `keosd` are accessible through the path.
* Know how to pass [Nodeos options](../../02_usage/00_nodeos-options.md) to enable or disable functionality.
## Steps
@@ -20,7 +20,7 @@ Open four "terminal" windows and perform the following steps:
1. [Start the Wallet Manager](#1-start-the-wallet-manager)
2. [Create a Default Wallet](#2-create-a-default-wallet)
3. [Loading the EOSIO Key](#3-loading-the-eosio-key)
3. [Loading the Antelope Key](#3-loading-the-antelope-key)
4. [Start the First Producer Node](#4-start-the-first-producer-node)
5. [Start the Second Producer Node](#5-start-the-second-producer-node)
6. [Get Nodes Info](#6-get-nodes-info)
@@ -66,7 +66,7 @@ Without password imported keys will not be retrievable.
`keosd` will generate some status output in its window. We will continue to use this second window for subsequent `cleos` commands.
### 3. Loading the EOSIO Key
### 3. Loading the Antelope Key
The private blockchain launched in the steps above is created with a default initial key which must be loaded into the wallet.
@@ -90,7 +90,8 @@ This creates a special producer, known as the "bios" producer. Assuming everythi
### 5. Start the Second Producer Node
The following commands assume that you are running this tutorial from the `eos\build` directory, from which you ran `./eosio_build.sh` to build the EOSIO binaries.
[//]: # (don't render for now)
[//]: # (The following commands assume that you are running this tutorial from the `eos\build` directory, from which you ran `./eosio_build.sh` to build the Antelope binaries.)
To start additional nodes, you must first load the `eosio.bios` contract. This contract enables you to have direct control over the resource allocation of other accounts and to access other privileged API calls. Return to the second terminal window and run the following command to load the contract:
@@ -142,7 +143,7 @@ We now have an account that is available to have a contract assigned to it, enab
In the fourth terminal window, start a second `nodeos` instance. Notice that this command line is substantially longer than the one we used above to create the first producer. This is necessary to avoid collisions with the first `nodeos` instance. Fortunately, you can just cut and paste this command line and adjust the keys:
The output from this new node will show a little activity but will stop reporting until the last step in this tutorial, when the `inita` account is registered as a producer account and activated. Here is some example output from a newly started node. Your output might look a little different, depending on how much time you took entering each of these commands. Furthermore, this example is only the last few lines of output:
@@ -8,24 +8,22 @@ There are several ways to configure a `nodeos` environment for development and t
This is the go-to option for smart contract developers, aspiring Block Producers or Non-Producing Node operators. It has the most simple configuration with the least number of requirements.
* [Configure Nodeos as a Local Single-node Testnet](00_local-single-node-testnet.md)
* [Configure Nodeos as a Local Single-node Testnet](00_local-single-node-testnet.md)
## Local Multi-Node Testnet
While this option can technically be used for smart contract development, it may be overkill. This is most beneficial for those who are working on aspects of core development, such as benchmarking, optimization and experimentation. It's also a good option for hands-on learning and concept proofing.
* [Configure Nodeos as a Local Two-Node Testnet](01_local-multi-node-testnet.md)
* [Configure Nodeos as a Local 21-Node Testnet](https://github.com/EOSIO/eos/blob/master/tutorials/bios-boot-tutorial/README.md)
* [Configure Nodeos as a Local 21-Node Testnet](/tutorials/bios-boot-tutorial.md)
## Official Testnet
## Official Testing Node
The official testnet is available for testing EOSIO dApps and smart contracts:
* [testnet.eos.io](https://testnet.eos.io/)
Try [Docker Utilities for Node Execution](https://github.com/AntelopeIO/DUNE) for the easiest way to get started, and for multi-platform support.
## Third-Party Testnets
The following third-party testnets are available for testing EOSIO dApps and smart contracts:
The following third-party testnets are available for testing Antelope dApps and smart contracts:
| The `history_plugin` that the `history_api_plugin` depends upon is deprecated and will no longer be maintained. Please use the [`state_history_plugin`](../state_history_plugin/index.md) instead.
## Description
The `history_api_plugin` exposes functionality from the [`history_plugin`](../history_plugin/index.md) to the RPC API interface managed by the [`http_plugin`](../http_plugin/index.md), providing read-only access to blockchain data.
It provides four RPC API endpoints:
* get_actions
* get_transaction
* get_key_accounts
* get_controlled_accounts
[[info | More Info]]
| See HISTORY section of [RPC API](https://developers.eos.io/eosio-nodeos/reference).
The four actions listed above are used by the following `cleos` commands (matching order):
| The `history_plugin` is deprecated and will no longer be maintained. Please use the [`state_history_plugin`](../state_history_plugin/index.md) instead.
## Description
The `history_plugin` provides a cache layer to obtain historical data about the blockchain objects. It depends on [`chain_plugin`](../chain_plugin/index.md) for the data.
The `http_client_plugin` is an internal utility plugin, providing the `producer_plugin` the ability to use securely an external `keosd` instance as its block signer. It can only be used when the `producer_plugin` is configured to produce blocks.
The `login_plugin` supports the concept of applications authenticating with the EOSIO blockchain. The `login_plugin` API allows an application to verify whether an account is allowed to sign in order to satisfy a specified authority.
## Usage
```console
# config.ini
plugin = eosio::login_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::login_plugin [options]
```
## Options
These can be specified from both the `nodeos` command-line or the `config.ini` file:
```console
Config Options for eosio::login_plugin:
--max-login-requests arg (=1000000) The maximum number of pending login
requests
--max-login-timeout arg (=60) The maximum timeout for pending login
@@ -8,7 +8,7 @@ The `net_api_plugin` provides four RPC API endpoints:
* connections
* status
See [Net API Reference Documentation](https://developers.eos.io/manuals/eos/latest/nodeos/plugins/net_api_plugin/api-reference/index).
See [Net API Reference Documentation](https://docs.eosnetwork.com/leap-plugins/latest/net.api/).
[[caution | Caution]]
| This plugin exposes endpoints that allow management of p2p connections. Running this plugin on a publicly accessible node is not recommended as it can be exploited.
--incoming-defer-ratio arg (=1) ratio between incoming transactions and
deferred transactions when both are
deferred transactions when both are
queued for execution
--incoming-transaction-queue-size-mb arg (=1024)
Maximum size (in MiB) of the incoming
Maximum size (in MiB) of the incoming
transaction queue. Exceeding this value
will subjectively drop transaction with
resource exhaustion.
--disable-api-persisted-trx Disable the re-apply of API
transactions.
--disable-subjective-billing arg (=1) Disable subjective CPU billing for
--disable-subjective-billing arg (=1) Disable subjective CPU billing for
API/P2P transactions
--disable-subjective-account-billing arg
Account which is excluded from
Account which is excluded from
subjective CPU billing
Account is considered whitelisted and
will not be subject to enforcement of
subjective-account-max-failures.
--disable-subjective-p2p-billing arg (=1)
Disable subjective CPU billing for P2P
Disable subjective CPU billing for P2P
transactions
--disable-subjective-api-billing arg (=1)
Disable subjective CPU billing for API
Disable subjective CPU billing for API
transactions
--producer-threads arg (=2) Number of worker threads in producer
--producer-threads arg (=2) Number of worker threads in producer
thread pool
--snapshots-dir arg (="snapshots") the location of the snapshots directory
(absolute path or relative to
(absolute path or relative to
application data dir)
```
@@ -172,7 +154,7 @@ The option below sets the ratio between the incoming transaction and the deferre
--incoming-defer-ratio arg (=1)
```
By default value of `1`, the `producer` plugin processes one incoming transaction per deferred transaction. When `arg` sets to `10`, the `producer` plugin processes 10 incoming transactions per deferred transaction.
By default value of `1`, the `producer` plugin processes one incoming transaction per deferred transaction. When `arg` sets to `10`, the `producer` plugin processes 10 incoming transactions per deferred transaction.
If the `arg` is set to a sufficiently large number, the plugin always processes the incoming transaction first until the queue of the incoming transactions is empty. Respectively, if the `arg` is 0, the `producer` plugin processes the deferred transactions queue first.
The `resource_monitor_plugin` monitors space usage in the computing system where `nodeos` is running. Specifically, every `resource-monitor-interval-seconds` seconds,
it measures the individual space used by each of the file systems mounted
by `data-dir`, `state-dir`, `blocks-log-dir`, `snapshots-dir`,
`state-history-dir`, and `trace-dir`.
When space usage in any of the monitored file system is within `5%` of the threshold
specified by `resource-monitor-space-threshold`, a warning containing the file system
path and percentage of space has used is printed out.
When space usage exceeds the threshold,
if `resource-monitor-not-shutdown-on-threshold-exceeded` is not set,
`nodeos` gracefully shuts down; if `resource-monitor-not-shutdown-on-threshold-exceeded` is set, `nodeos` prints out warnings periodically
until space usage goes under the threshold.
The `resource_monitor_plugin` monitors space usage in the computing system where `nodeos` is running. Specifically, every `resource-monitor-interval-seconds` seconds, it measures the individual space used by each of the file systems mounted by `data-dir`, `state-dir`, `blocks-log-dir`, `snapshots-dir`, `state-history-dir`, and `trace-dir`. When space usage in any of the monitored file system is within `5%` of the threshold specified by `resource-monitor-space-threshold`, a warning containing the file system path and percentage of space has used is printed out. When space usage exceeds the threshold, if `resource-monitor-not-shutdown-on-threshold-exceeded` is not set, `nodeos` gracefully shuts down; if `resource-monitor-not-shutdown-on-threshold-exceeded` is set, `nodeos` prints out warnings periodically until space usage goes under the threshold.
`resource_monitor_plugin` is always loaded.
## Usage
```console
@@ -32,33 +23,28 @@ These can be specified from both the `nodeos` command-line or the `config.ini` f
```console
Config Options for eosio::resource_monitor_plugin:
@@ -5,11 +5,11 @@ The `trace_api_plugin` provides a consumer-focused long-term API for retrieving
## Purpose
While integrating applications such as block explorers and exchanges with an EOSIO blockchain, the user might require a complete transcript of actions processed by the blockchain, including those spawned from the execution of smart contracts and scheduled transactions. The `trace_api_plugin` serves this need. The purpose of the plugin is to provide:
While integrating applications such as block explorers and exchanges with an Antelope blockchain, the user might require a complete transcript of actions processed by the blockchain, including those spawned from the execution of smart contracts and scheduled transactions. The `trace_api_plugin` serves this need. The purpose of the plugin is to provide:
* A transcript of retired actions and related metadata
* A consumer-focused long-term API to retrieve blocks
* Maintainable resource commitments at the EOSIO nodes
* Maintainable resource commitments at the Antelope nodes
Therefore, one crucial goal of the `trace_api_plugin` is to improve the maintenance of node resources (file system, disk space, memory used, etc.). This goal is different from the existing `history_plugin` which provides far more configurable filtering and querying capabilities, or the existing `state_history_plugin` which provides a binary streaming interface to access structural chain data, action data, as well as state deltas.
@@ -191,7 +191,7 @@ If resource usage cannot be effectively managed via the `trace-minimum-irreversi
## Manual Maintenance
The `trace-dir` option defines the directory on the filesystem where the trace log files are stored by the `trace_api_plugin`. These files are stable once the LIB block has progressed past a given slice and then can be deleted at any time to reclaim filesystem space. The deployed EOSIO system will tolerate any out-of-process management system that removes some or all of these files in this directory regardless of what data they represent, or whether there is a running `nodeos` instance accessing them or not. Data which would nominally be available, but is no longer so due to manual maintenance, will result in a HTTP 404 response from the appropriate API endpoint(s).
The `trace-dir` option defines the directory on the filesystem where the trace log files are stored by the `trace_api_plugin`. These files are stable once the LIB block has progressed past a given slice and then can be deleted at any time to reclaim filesystem space. The deployed Antelope system will tolerate any out-of-process management system that removes some or all of these files in this directory regardless of what data they represent, or whether there is a running `nodeos` instance accessing them or not. Data which would nominally be available, but is no longer so due to manual maintenance, will result in a HTTP 404 response from the appropriate API endpoint(s).
[[info | For node operators]]
| Node operators can take full control over the lifetime of the historical data available in their nodes via the `trace-api-plugin` and the `trace-minimum-irreversible-history-blocks` and `trace-minimum-uncompressed-irreversible-history-blocks` options in conjunction with any external filesystem resource manager.
The `txn_test_gen_plugin` is used for transaction test purposes.
[[info | For More Information]]
For more information, check the [txn_test_gen_plugin/README.md](https://github.com/EOSIO/eos/blob/develop/plugins/txn_test_gen_plugin/README.md) on the EOSIO/eos repository.
data/snapshots | <head block id in hex>.bin | place the snapshot file you want to replay here
data/snapshots | `<head block id in hex>.bin` | place the snapshot file you want to replay here
data/ | * | remove
You can use `snapshots-dir = "snapshots" ` in the configuration file or using the `--snapshots-dir` command line option, to specify the where to find the the snapshot to replay, use `--snapshot` to specify the name of the snapshot to replay.
@@ -17,7 +17,7 @@ Snapshot files can be created from a running `nodeos` instance. The snapshot con
* [How To Generate a Blocks Log](how-to-generate-a-blocks.log.md)
* [How To Generate a Snapshot](how-to-generate-a-snapshot.md)
* [How To Replay from a Blocks Log](how-to-replay-from-a-blocks.log.md)
* [How to Replay from a Snapshot](how-to-replay-from-a-snapshot.md)
* [How to Replay from a Snapshot](../04_replays/how-to-replay-from-a-snapshot.md)
## Replay Snapshot-specific Options
@@ -41,9 +41,9 @@ This tells `nodeos` to clear the local chain state and local the `blocks.log` fi
- **--truncate-at-block**
Default argument (=0), only used if the given value is non-zero.
Using this option when replaying the blockchain will force the replay to stop at the specified block number. This option will only work if replaying with the `--hard-replay-blockchain` option. The local `nodeos` process will contain the chain state for that block. This option may be useful for checking blockchain state at specific points in time. It is intended for testing/validation and is not intended to be used when creating a local `nodeos` instance which is synchronized with the network.
- **--snapshot**
Use this option to specify which snapshot file to use to recreate the chain state from a snapshot file. This option will not replay the `blocks.log` file. The `nodeos` instance will not know the full transaction history of the blockchain.
Use this option to specify which snapshot file to use to recreate the chain state from a snapshot file. This option will not replay the `blocks.log` file. The `nodeos` instance will not know the full transaction history of the blockchain.
- **--snapshots-dir**
You can use this to specify the location of the snapshot file directory (absolute path or relative to application data dir.)
* `error` - Log output that likely requires operator intervention.
- Error level logging should be reserved for conditions that are completely unexpected or otherwise need human intervention.
- Also used to indicate software errors such as: impossible values for an `enum`, out of bounds array access, null pointers, or other conditions that likely will throw an exception.
- *Note*: Currently, there are numerous `error` level logging that likely should be `warn` as they do not require human intervention. The `net_plugin_impl`, for example, has a number of `error` level logs for bad network connections. This is handled and processed correctly. These should be changed to `warn` or `info`.
* `warn` - Log output indicating unexpected but recoverable errors.
- Although, `warn` level typically does not require human intervention, repeated output of `warn` level logs might indicate actions needed by an operator.
- `warn` should not be used simply for conveying information. A `warn` level log is something to take notice of, but not necessarily be concerned about.
* `info` (default) - Log output that provides useful information to an operator.
- Can be just progress indication or other useful data to a user. Care is taken not to create excessive log output with `info` level logging. For example, no `info` level logging should be produced for every transaction.
- For progress indication, some multiple of transactions should be processed between each log output; typically, every 1000 transactions.
* `debug` - Useful log output for when non-default logging is enabled.
- Answers the question: is this useful information for a user that is monitoring the log output. Care should be taken not to create excessive log output; similar to `info` level logging.
- Enabling `debug` level logging should provide greater insight into behavior without overwhelming the output with log entries.
- `debug` level should not be used for *trace* level logging; to that end, use `all` (see below).
- Like `info`, no `debug` level logging should be produced for every transaction. There are specific transaction level loggers dedicated to transaction level logging: `transaction`, `transaction_trace_failure`, `transaction_trace_success`, `transaction_failure_tracing`, `transaction_success_tracing`, `transient_trx_success_tracing`, `transient_trx_failure_tracing`.
* `all` (trace) - For logging that would be overwhelming if `debug` level logging were used.
- Can be used for trace level logging. Only used in a few places and not completely supported.
- *Note*: In the future a different logging library may provide better trace level logging support. The current logging framework is not performant enough to enable excess trace level output.
The EOSIO platform stores blockchain information in various data structures at various stages of a transaction's lifecycle. Some of these are described below. The producing node is the `nodeos` instance run by the block producer who is currently creating blocks for the blockchain (which changes every 6 seconds, producing 12 blocks in sequence before switching to another producer.)
The Antelope platform stores blockchain information in various data structures at various stages of a transaction's lifecycle. Some of these are described below. The producing node is the `nodeos` instance run by the block producer who is currently creating blocks for the blockchain (which changes every 6 seconds, producing 12 blocks in sequence before switching to another producer.)
## Blockchain State and Storage
@@ -15,9 +15,9 @@ Every `nodeos` instance creates some internal files to housekeep the blockchain
* The `pending block` is an in memory block containing transactions as they are processed and pushed into the block; this will/may eventually become the head block. If the `nodeos` instance is the producing node, the pending block is distributed to other `nodeos` instances.
* Outside the chain state, block data is cached in RAM until it becomes final/irreversible; especifically the signed block itself. After the last irreversible block (LIB) catches up to the block, that block is then retrieved from the irreversible blocks log.
## EOSIO Interfaces
## Antelope Interfaces
EOSIO provides a set of [services](../../) and [interfaces](https://developers.eos.io/manuals/eosio.cdt/latest/files) that enable contract developers to persist state across action, and consequently transaction, boundaries. Contracts may use these services and interfaces for various purposes. For example, `eosio.token` contract keeps balances for all users in the chain database. Each instance of `nodeos` keeps the database in memory, so contracts can read and write data with ease.
Antelope provides a set of [services](../../) and [interfaces](https://docs.eosnetwork.com/cdt/latest/reference/Files/) that enable contract developers to persist state across action, and consequently transaction, boundaries. Contracts may use these services and interfaces for various purposes. For example, `eosio.token` contract keeps balances for all users in the chain database. Each instance of `nodeos` keeps the database in memory, so contracts can read and write data with ease.
### Nodeos RPC API
@@ -27,41 +27,20 @@ The `nodeos` service provides query access to the chain database via the HTTP [R
The `nodeos` service can be run in different "read" modes. These modes control how the node operates and how it processes blocks and transactions:
- `speculative`: this includes the side effects of confirmed and unconfirmed transactions.
- `head`: this only includes the side effects of confirmed transactions, this mode processes unconfirmed transactions but does not include them.
- `read-only`: this mode is deprecated. Similar functionality can be achieved by combining options: `read-mode = head`, `p2p-accept-transactions = false`, `api-accept-transactions = false`. When these options are set, the local database will contain state changes made by transactions in the chain up to the head block. Also, transactions received via the P2P network are not relayed and transactions cannot be pushed via the chain API.
- `irreversible`: this mode also includes confirmed transactions only up to those included in the last irreversible block.
A transaction is considered confirmed when a `nodeos` instance has received, processed, and written it to a block on the blockchain, i.e. it is in the head block or an earlier block.
### Speculative Mode
Clients such as `cleos` and the RPC API, will see database state as of the current head block plus changes made by all transactions known to this node but potentially not included in the chain, unconfirmed transactions for example.
Speculative mode is low latency but fragile, there is no guarantee that the transactions reflected in the state will be included in the chain OR that they will reflected in the same order the state implies.
This mode features the lowest latency, but is the least consistent.
In speculative mode `nodeos` is able to execute transactions which have TaPoS (Transaction as Proof of Stake) pointing to any valid block in a fork considered to be the best fork by this node.
### Head Mode
Clients such as `cleos` and the RPC API will see database state as of the current head block of the chain. Since current head block is not yet irreversible and short-lived forks are possible, state read in this mode may become inaccurate if `nodeos` switches to a better fork. Note that this is also true of speculative mode.
This mode represents a good trade-off between highly consistent views of the data and latency.
Clients such as `cleos` and the RPC API will see database state as of the current head block of the chain. Since current head block is not yet irreversible and short-lived forks are possible, state read in this mode may become inaccurate if `nodeos` switches to a better fork.
In this mode `nodeos` is able to execute transactions which have TaPoS pointing to any valid block in a fork considered to be the best fork by this node.
### Read-Only Mode
[[caution | Deprecation Notice]]
| The explicit `read-mode = read-only` mode is deprecated. Similar functionality can now be achieved in `head` mode by combining options: `read-mode = head`, `p2p-accept-transactions = false`, `api-accept-transactions = false`.
Clients such as `cleos` and the RPC API will see database state as of the current head block of the chain. It **will not** include changes made by transactions known to this node but not included in the chain, such as unconfirmed transactions.
### Irreversible Mode
When `nodeos` is configured to be in irreversible read mode, it will still track the most up-to-date blocks in the fork database, but the state will lag behind the current best head block, sometimes referred to as the fork DB head, to always reflect the state of the last irreversible block.
When `nodeos` is configured to be in irreversible read mode, it will still track the most up-to-date blocks in the fork database, but the state will lag behind the current best head block, sometimes referred to as the fork DB head, to always reflect the state of the last irreversible block.
Clients such as `cleos` and the RPC API will see database state as of the current head block of the chain. It **will not** include changes made by transactions known to this node but not included in the chain, such as unconfirmed transactions.
The immutable nature of the blockchain allows data to be stored securely while also enforcing the integrity of such data. However, this benefit also complicates the removal of non-essential data from the blockchain. Consequently, EOSIO blockchains contain a special section within the transaction, called the *context-free data*. As its name implies, data stored in the context-free data section is considered free of previous contexts or dependencies, which makes their potential removal possible. More importantly, such removal can be performed safely without compromising the integrity of the blockchain.
The immutable nature of the blockchain allows data to be stored securely while also enforcing the integrity of such data. However, this benefit also complicates the removal of non-essential data from the blockchain. Consequently, Antelope blockchains contain a special section within the transaction, called the *context-free data*. As its name implies, data stored in the context-free data section is considered free of previous contexts or dependencies, which makes their potential removal possible. More importantly, such removal can be performed safely without compromising the integrity of the blockchain.
## Concept
The goal of context-free data is to allow blockchain applications the option to store non-essential information within a transaction. Some examples of context-free data include:
### "Database dirty flag set (likely due to unclean shutdown): replay required"
`nodeos` needs to be shut down cleanly. To ensure this is done, send a `SIGTERM`, `SIGQUIT` or `SIGINT` and wait for the process to shutdown. Failing to do this will result in this error. If you get this error, your only recourse is to replay by starting `nodeos` with `--replay-blockchain`
`nodeos` needs to be shut down cleanly. To ensure this is done, send a `SIGTERM`, `SIGQUIT` or `SIGINT` and wait for the process to shutdown. Failing to do this will result in this error. If you get this error, your only recourse is to replay by starting `nodeos` with `--replay-blockchain`
### "Memory does not match data" Error at Restart
@@ -12,15 +12,15 @@ If you get an error such as `St9exception: content of memory does not match data
```
Command Line Options for eosio::chain_plugin:
--force-all-checks do not skip any checks that can be
skipped while replaying irreversible
--force-all-checks do not skip any checks that can be
skipped while replaying irreversible
blocks
--replay-blockchain clear chain state database and replay
--replay-blockchain clear chain state database and replay
all blocks
--hard-replay-blockchain clear chain state database, recover as
many blocks as possible from the block
--hard-replay-blockchain clear chain state database, recover as
many blocks as possible from the block
log, and then replay those blocks
--delete-all-blocks clear chain state database and block
--delete-all-blocks clear chain state database and block
log
```
@@ -28,7 +28,7 @@ Command Line Options for eosio::chain_plugin:
Start `nodeos` with `--shared-memory-size-mb 1024`. A 1 GB shared memory file allows approximately half a million transactions.
### What version of EOSIO am I running/connecting to?
### What version of Antelope am I running/connecting to?
If defaults can be used, then `cleos get info` will output a block that contains a field called `server_version`. If your `nodeos` is not using the defaults, then you need to know the URL of the `nodeos`. In that case, use the following with your `nodeos` URL:
@@ -44,4 +44,4 @@ cleos --url http://localhost:8888 get info | grep server_version
### Error 3070000: WASM Exception Error
If you try to deploy the `eosio.bios` contract or `eosio.system` contract in an attempt to boot an EOSIO-based blockchain and you get the following error or similar: `Publishing contract... Error 3070000: WASM Exception Error Details: env.set_proposed_producers_ex unresolveable`, it is because you have to activate the `PREACTIVATE_FEATURE` protocol first. More details about it and how to enable it can be found in the [Bios Boot Sequence Tutorial](https://developers.eos.io/welcome/latest/tutorials/bios-boot-sequence/#112-set-the-eosiosystem-contract). For more information, you may also visit the [Nodeos Upgrade Guides](https://developers.eos.io/manuals/eos/latest/nodeos/upgrade-guides/).
If you try to deploy the `eosio.bios` contract or `eosio.system` contract in an attempt to boot an Antelope-based blockchain and you get the following error or similar: `Publishing contract... Error 3070000: WASM Exception Error Details: env.set_proposed_producers_ex unresolveable`, it is because you have to activate the `PREACTIVATE_FEATURE` protocol first.
`nodeos` is the core service daemon that runs on every EOSIO node. It can be configured to process smart contracts, validate transactions, produce blocks containing valid transactions, and confirm blocks to record them on the blockchain.
`nodeos` is the core service daemon that runs on every Antelope node. It can be configured to process smart contracts, validate transactions, produce blocks containing valid transactions, and confirm blocks to record them on the blockchain.
## Installation
`nodeos` is distributed as part of the [EOSIO software suite](https://github.com/EOSIO/eos/blob/master/README.md). To install `nodeos`, visit the [EOSIO Software Installation](../00_install/index.md) section.
`nodeos` is distributed as part of the [Antelope software suite](https://github.com/AntelopeIO/leap). To install `nodeos`, visit the [Antelope Software Installation](../00_install/index.md) section.
## Explore
@@ -21,7 +21,6 @@ Navigate the sections below to configure and use `nodeos`.
@@ -11,11 +11,11 @@ Make sure you meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Understand what an [account](https://developers.eos.io/welcome/latest/glossary/index/#account) is and its role in the blockchain.
* Understand [Accounts and Permissions](https://developers.eos.io/welcome/latest/protocol-guides/accounts_and_permissions) in the protocol documents.
* Understand what a [public](https://developers.eos.io/welcome/latest/glossary/index/#public-key) and [private](https://developers.eos.io/welcome/latest/glossary/index/#private-key) key pair is.
* Understand what an [account](/glossary.md#account) is and its role in the blockchain.
* Understand [Accounts and Permissions](/protocol-guides/04_accounts_and_permissions.md) in the protocol documents.
* Understand what a [public](/glossary.md#public-key) and [private](/glossary.md#private-key) key pair is.
This how-to guide provides instructions on how to create a new EOSIO blockchain account using the `cleos` CLI tool. You can use accounts to deploy smart contracts and perform other related blockchain operations. Create one or multiple accounts as part of your development environment setup.
This how-to guide provides instructions on how to create a new Antelope blockchain account using the `cleos` CLI tool. You can use accounts to deploy smart contracts and perform other related blockchain operations. Create one or multiple accounts as part of your development environment setup.
The example in this how-to guide creates a new account named **bob**, authorized by the default system account **eosio**, using the `cleos` CLI tool.
The example in this how-to guide creates a new account named **bob**, authorized by the default system account **eosio**, using the `cleos` CLI tool.
## Before you Begin
@@ -10,9 +10,9 @@ Make sure you meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| The cleos tool is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install the cleos tool.
* Learn about [EOSIO Accounts and Permissions](https://developers.eos.io/welcome/v2.1/protocol/accounts_and_permissions)
* Learn about Asymmetric Cryptography - [public key](https://developers.eos.io/welcome/v2.1/glossary/index#public-key) and [private key](https://developers.eos.io/welcome/v2.1/glossary/index#private-key) pairs.
| The cleos tool is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install the cleos tool.
* Learn about [Antelope Accounts and Permissions](/protocol-guides/04_accounts_and_permissions.md)
* Learn about Asymmetric Cryptography - [public key](/glossary.md#public-key) and [private key](/glossary.md#private-key) pairs.
* Create public/private keypairs for the `owner` and `active` permissions of an account.
## Command Reference
@@ -31,10 +31,10 @@ cleos create account eosio bob EOS87TQktA5RVse2EguhztfQVEh6XXxBmgkU8b4Y5YnGvtYAo
```
**Where**:
* `eosio` = the system account that authorizes the creation of a new account
* `bob` = the name of the new account conforming to [account naming conventions](https://developers.eos.io/welcome/v2.1/protocol-guides/accounts_and_permissions#2-accounts)
* `bob` = the name of the new account conforming to [account naming conventions](/protocol-guides/04_accounts_and_permissions.md#2-accounts)
* `EOS87TQ...AoLGNN` = the owner public key or permission level for the new account (**required**)
[[info | Note]]
| To create a new account in the EOSIO blockchain, an existing account, also referred to as a creator account, is required to authorize the creation of a new account. For a newly created EOSIO blockchain, the default system account used to create a new account is **eosio**.
| To create a new account in the Antelope blockchain, an existing account, also referred to as a creator account, is required to authorize the creation of a new account. For a newly created Antelope blockchain, the default system account used to create a new account is **eosio**.
**Example Output**
@@ -46,4 +46,4 @@ warning: transaction executed locally, but may not be confirmed by the network y
### Summary
By following these instructions, you are able to create a new EOSIO account in your blockchain environment.
By following these instructions, you are able to create a new Antelope account in your blockchain environment.
This how-to guide provides instructions on how to create a keypair consisting of a public key and a private key for signing transactions in an EOSIO blockchain.
This how-to guide provides instructions on how to create a keypair consisting of a public key and a private key for signing transactions in an Antelope blockchain.
## Before you begin
Make sure you meet the following requirements:
* Install the currently supported version of `cleos`
[[info | Note]]
| The cleos tool is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install the cleos tool.
* Learn about asymmetric cryptography (public and private keypair) in the context of an EOSIO blockchain.
| The cleos tool is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install the cleos tool.
* Learn about asymmetric cryptography (public and private keypair) in the context of an Antelope blockchain.
@@ -10,12 +10,12 @@ Make sure you meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Ensure the reference system contracts from [`eosio.contracts`](https://github.com/EOSIO/eosio.contracts) repository is deployed and used to manage system resources.
* Understand what an [account](https://developers.eos.io/welcome/latest/glossary/index/#account) is and its role in the blockchain.
* Understand [CPU bandwidth](https://developers.eos.io/welcome/latest/glossary/index/#cpu) in an EOSIO blockchain.
* Understand [NET bandwidth](https://developers.eos.io/welcome/latest/glossary/index/#net) in an EOSIO blockchain.
* Ensure the reference system contracts from [`reference-contracts`](https://github.com/AntelopeIO/reference-contracts) repository is deployed and used to manage system resources.
* Understand what an [account](/glossary.md#account) is and its role in the blockchain.
* Understand [CPU bandwidth](/glossary.md#cpu) in an Antelope blockchain.
* Understand [NET bandwidth](/glossary.md#net) in an Antelope blockchain.
@@ -10,12 +10,12 @@ Make sure you meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Ensure the reference system contracts from [`eosio.contracts`](https://github.com/EOSIO/eosio.contracts) repository is deployed and used to manage system resources.
* Understand what an [account](https://developers.eos.io/welcome/latest/glossary/index/#account) is and its role in the blockchain.
* Understand [NET bandwidth](https://developers.eos.io/welcome/latest/glossary/index/#net) in an EOSIO blockchain.
* Understand [CPU bandwidth](https://developers.eos.io/welcome/latest/glossary/index/#cpu) in an EOSIO blockchain.
* Ensure the reference system contracts from [`reference-contracts`](https://github.com/AntelopeIO/reference-contracts) repository is deployed and used to manage system resources.
* Understand what an [account](/glossary.md#account) is and its role in the blockchain.
* Understand [NET bandwidth](/glossary.md#net) in an Antelope blockchain.
* Understand [CPU bandwidth](/glossary.md#cpu) in an Antelope blockchain.
This how-to guide provides instructions on how to query infomation of an EOSIO account. The example in this how-to guide retrieves information of the `eosio` account.
This how-to guide provides instructions on how to query infomation of an Antelope account. The example in this how-to guide retrieves information of the `eosio` account.
## Before you begin
* Install the currently supported version of `cleos`
[[info | Note]]
| The cleos tool is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install the cleos tool.
| The cleos tool is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install the cleos tool.
* Acquire functional understanding of [EOSIO Accounts and Permissions](https://developers.eos.io/welcome/v2.1/protocol/accounts_and_permissions)
* Acquire functional understanding of [Antelope Accounts and Permissions](/protocol-guides/04_accounts_and_permissions.md)
## Command Reference
@@ -28,7 +28,7 @@ cleos get account eosio
```
**Where**:
* `eosio` = The name of the default system account in the EOSIO blockchain.
* `eosio` = The name of the default system account in the Antelope blockchain.
**Example Output**
@@ -53,4 +53,4 @@ cpu bandwidth:
```
[[info | Account Fields]]
| Depending on the EOSIO network you are connected, you might see different fields associated with an account. That depends on which system contract has been deployed on the network.
| Depending on the Antelope network you are connected, you might see different fields associated with an account. That depends on which system contract has been deployed on the network.
@@ -10,10 +10,10 @@ Make sure to meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Understand what a [block](https://developers.eos.io/welcome/latest/glossary/index/#block) is and its role in the blockchain.
* Understand the [block lifecycle](https://developers.eos.io/welcome/latest/protocol-guides/consensus_protocol/#5-block-lifecycle) in the EOSIO consensus protocol.
* Understand what a [block](/glossary.md#block) is and its role in the blockchain.
* Understand the [block lifecycle](/protocol-guides/01_consensus_protocol.md#5-block-lifecycle) in the Antelope consensus protocol.
## Steps
@@ -34,8 +34,10 @@ Some examples are provided below:
**Example Output**
```sh
cleos -u https://api.testnet.eos.io get block 48351112
cleos -u https://choiceofyourprovider get block 48351112
```
Reference to [testnet providers](/resources/index.md)
```json
{
"timestamp": "2021-01-28T17:58:59.500",
@@ -59,7 +61,7 @@ cleos -u https://api.testnet.eos.io get block 48351112
**Example Output**
```sh
cleos -u https://api.testnet.eos.io get block 02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba
cleos -u https://choiceofyourprovider get block 02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba
This how-to guide provides instructions on how to retrieve infomation of an EOSIO transaction using a transaction ID.
This how-to guide provides instructions on how to retrieve infomation of an Antelope transaction using a transaction ID.
The example in this how-to retrieves transaction information associated with the creation of the account **bob**.
The example in this how-to retrieves transaction information associated with the creation of the account **bob**.
## Before you begin
Make sure you meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
* Understand how transactions work in an EOSIO blockchain. For more information on transactions, see the [Transactions Protocol](https://developers.eos.io/welcome/latest/protocol-guides/transactions_protocol) section.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Understand how transactions work in an Antelope blockchain. For more information on transactions, see the [Transactions Protocol](/protocol-guides/02_transactions_protocol.md) section.
## Command Reference
@@ -25,7 +25,7 @@ The following step shows how to retrieve transaction information associated with
```sh
cleos get transaction 870a6b6e3882061ff0f64016e1eedfdd9439e2499bf978c3fb29fcedadada9b1
```
* Where `870a6b6e38...dada9b1`= The transaction ID associated with the creation of account **bob**.
* Where `870a6b6e38...dada9b1`= The transaction ID associated with the creation of account **bob**.
**Example Output**
@@ -179,7 +179,7 @@ The `cleos` command returns detailed information of the transaction:
## Summary
By following these instructions, you are able to retrieve transaction information using a transaction ID.
By following these instructions, you are able to retrieve transaction information using a transaction ID.
## Trobleshooting
@@ -195,4 +195,4 @@ Error Details:
History API plugin is not enabled
```
To troubleshoot this error, enable the [history plugin](../../01_nodeos/03_plugins/history_plugin/index.md) and [history API plugin](../../01_nodeos/03_plugins/history_api_plugin/index.md), then run the command again.
To troubleshoot this error, enable the [history plugin](../../01_nodeos/03_plugins/history_plugin/index.md) and [history API plugin](../../01_nodeos/03_plugins/history_api_plugin/index.md), then run the command again.
This how-to guide provides instructions on how to import a private key into the `keosd` default wallet. You can use the private key to authorize transactions in an EOSIO blockchain.
This how-to guide provides instructions on how to import a private key into the `keosd` default wallet. You can use the private key to authorize transactions in an Antelope blockchain.
## Before you Begin
Make sure you meet the following requirements:
* Create a default wallet using the `cleos wallet create` command. See the [How to Create a Wallet](../02_how-to-guides/how-to-create-a-wallet.md) section for instructions.
* Create a default wallet using the `cleos wallet create` command. See the [How to Create a Wallet](../02_how-to-guides/how-to-create-a-wallet.md) section for instructions.
* Open and unlock the created wallet.
* Familiarize with the [`cleos wallet import`](../03_command-reference/wallet/import.md) command.
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
* Understand what a [public key](https://developers.eos.io/welcome/latest/glossary/index/#public-key) and [private key](https://developers.eos.io/welcome/latest/glossary/index/#private-key) is.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Understand what a [public key](/glossary.md#public-key) and [private key](/glossary.md#private-key) is.
This how-to guide provides instructions on how to list all public keys and public/private key pairs within the `keosd` default wallet. You can use the public and private keys to authorize transactions in an EOSIO blockchain.
This how-to guide provides instructions on how to list all public keys and public/private key pairs within the `keosd` default wallet. You can use the public and private keys to authorize transactions in an Antelope blockchain.
The example in this how-to guide displays all public keys and public/private key pairs stored within the existing default wallet.
@@ -8,13 +8,13 @@ The example in this how-to guide displays all public keys and public/private key
Make sure you meet the following requirements:
* Create a default wallet using the `cleos wallet create` command. See the [How to Create a Wallet](../02_how-to-guides/how-to-create-a-wallet.md) section for instructions.
* Create a default wallet using the `cleos wallet create` command. See the [How to Create a Wallet](../02_how-to-guides/how-to-create-a-wallet.md) section for instructions.
* [Create a keypair](../03_command-reference/wallet/create_key.md) within the default wallet.
* Familiarize with the [`cleos wallet`](../03_command-reference/wallet/index.md) commands.
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../00_install/index.md) will also install `cleos`.
* Understand what a [public key](https://developers.eos.io/welcome/latest/glossary/index/#public-key) and [private key](https://developers.eos.io/welcome/latest/glossary/index/#private-key) is.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../00_install/index.md) will also install `cleos`.
* Understand what a [public key](/glossary.md#public-key) and [private key](/glossary.md#private-key) is.
## Command Reference
@@ -71,7 +71,7 @@ cleos wallet private_keys
password:
```
6. Enter the generated password when you created the default wallet:
6. Enter the generated password when you created the default wallet:
```sh
***
```
@@ -86,7 +86,7 @@ password: [[
```
[[caution | Warning]]
| Never reveal your private keys in a production environment.
| Never reveal your private keys in a production environment.
[[info | Note]]
| If the above commands does not list any keys, make sure you have created keypairs and imported private keys to your wallet.
* [OPTIONS] = See **Options** in the [**Command Usage**](command-usage) section below.
* [OPTIONS] = See **Options** section TBD
[//]: # ( THIS IS A COMMENT LINK BELOW IS BROKEN )
[//]: # (in the **Command Usage** command-usage section below.)
* host = The hostname:port to connect to
**Note:** The arguments and options enclosed in square brackets are optional.
@@ -26,7 +30,7 @@ Make sure you meet the following requirements:
* Install the currently supported version of `cleos`.
[[info | Note]]
| `cleos` is bundled with the EOSIO software. [Installing EOSIO](../../../00_install/index.md) will also install the `cleos` and `keosd` command line tools.
| `cleos` is bundled with the Antelope software. [Installing Antelope](../../../00_install/index.md) will also install the `cleos` and `keosd` command line tools.
* You have access to a producing node instance with the [`net_api_plugin`](../../../01_nodeos/03_plugins/net_api_plugin/index.md) loaded.
## Examples
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Clayton Calabrese