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
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.
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.
2022-08-02 15:53:47 -05:00
1450 changed files with 82152 additions and 23270 deletions
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+, curl, 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.
#### Manual (non "pinned") Build Instructions
These 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 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 \
libgmp-dev \
libssl-dev \
llvm-11-dev
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:
content_title: Build EOSIO from Source on Other Unix-based 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/eosnetworkfoundation/DUNE) which runs in an ubuntu image via a docker container.
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.
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 file. Instructions are also included for efficiently running the tests.
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.
### Using DUNE
As an alternative to building from source try [Docker Utilities for Node Execution](https://github.com/eosnetworkfoundation/DUNE) for the easiest way to get started, and for multi-platform support.
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.
### 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 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).
You can also 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).
#### Building Pinned Build Binary Packages
In the directory `<mandel 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> <mandel 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 mandel build directory that was supplied.
The pinned build instructions 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.
After building you may remove the `$HOME/boost1.79` directory, or you may keep it around until next time building the software.
</details>
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
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.
ctest -L "long_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).
The best way to install and use the EOSIO software is to build it from source:
The best way to install and use the Antelope software is to build it from source:
* [Build EOSIO from Source](01_build-from-source/index.md)
* [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. Ubuntu 18.04
2. Ubuntu 20.04
3. Ubuntu 22.04
1. Ubuntu 22.04 Jammy
2. Ubuntu 20.04 Focal
3. Ubuntu 18.04 Bionic
[[info | Note]]
| It may be possible to build and install EOSIO 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.
| 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 EOSIO on Other Unix-based Systems](01_build-from-source/00_build-unsupported-os.md)
* [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 EOSIO from source you can try our Docker - based set of utilities called DUNE that can get you started with exploring EOSIO and doing contract development pretty much instantly
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/eosnetworkfoundation/DUNE)
* [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.
* [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 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 )
[//]: # ( 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.
@@ -53,7 +53,7 @@ producer-name = youraccount
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.
*`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.
* [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 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 )
[//]: # ( 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.
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,11 +12,11 @@ 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.
* [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 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 .)
[//]: # (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.
@@ -10,7 +10,7 @@ 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.
* [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.
@@ -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:
@@ -19,11 +19,11 @@ While this option can technically be used for smart contract development, it may
## Official Testing Node
Try [Docker Utilities for Node Execution](https://github.com/eosnetworkfoundation/DUNE) for the easiest way to get started, and for multi-platform support.
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
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://docs.eosnetwork.com/reference/mandel-plugins/net_api.html).
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.
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/eosnetworkfoundation/mandel/tree/main/plugins/txn_test_gen_plugin) on the EOSIO/eos repository.
*`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://docs.eosnetwork.com/reference/mandel-cdt/files.html) 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,38 +27,17 @@ 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.
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:
@@ -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.
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/eosnetworkfoundation/mandel). 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
@@ -23,4 +23,4 @@ Navigate the sections below to configure and use `nodeos`.
* [Troubleshooting](08_troubleshooting/index.md) - Common `nodeos` troubleshooting questions.
[[info | Access Node]]
| A local or remote EOSIO access node running `nodeos` is required for a client application or smart contract to interact with the blockchain.
| A local or remote Antelope access node running `nodeos` is required for a client application or smart contract to interact with the blockchain.
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.
@@ -10,8 +10,8 @@ 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](/protocol-guides/04_accounts_and_permissions.md)
| 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.
@@ -34,7 +34,7 @@ cleos create account eosio bob EOS87TQktA5RVse2EguhztfQVEh6XXxBmgkU8b4Y5YnGvtYAo
*`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/eosnetworkfoundation/mandel-contracts) repository is deployed and used to manage system resources.
* 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 EOSIO blockchain.
* Understand [NET bandwidth](/glossary.md#net) in an EOSIO 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/eosnetworkfoundation/mandel-contracts) repository is deployed and used to manage system resources.
* 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 EOSIO blockchain.
* Understand [CPU bandwidth](/glossary.md#cpu) in an EOSIO 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](/protocol-guides/04_accounts_and_permissions.md)
* 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.
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**.
@@ -9,8 +9,8 @@ The example in this how-to retrieves transaction information associated with the
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](/protocol-guides/02_transactions_protocol.md) 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.
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
@@ -11,7 +11,7 @@ Make sure you meet the following requirements:
* 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`.
| `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.
@@ -13,7 +13,7 @@ Make sure you meet the following requirements:
* 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`.
| `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.
@@ -30,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.
@@ -28,7 +28,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.
@@ -27,7 +27,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.
@@ -30,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.
| This command involves specifying JSON input which depends on underlying class definitions. Therefore, such JSON input is subject to change in future versions of the EOSIO software.
| This command involves specifying JSON input which depends on underlying class definitions. Therefore, such JSON input is subject to change in future versions of the Antelope software.
## Positionals
-`account`_TEXT_ - The account to set/delete a permission authority for
@@ -20,4 +20,4 @@ Replace API_ENDPOINT and PORT with your remote `nodeos` API endpoint detail
## "Missing Authorizations"
That means you are not using the required authorizations. Most likely you are not using correct EOSIO account or permission level to sign the transaction
That means you are not using the required authorizations. Most likely you are not using correct Antelope account or permission level to sign the transaction
`cleos` is a command line tool that interfaces with the REST API exposed by `nodeos`. Developers can also use `cleos` to deploy and test EOSIO smart contracts.
`cleos` is a command line tool that interfaces with the REST API exposed by `nodeos`. Developers can also use `cleos` to deploy and test Antelope smart contracts.
## Installation
`cleos` is distributed as part of the [EOSIO software suite](https://github.com/eosnetworkfoundation/mandel). To install `cleos` just visit the [EOSIO Software Installation](../00_install/index.md) section.
`cleos` is distributed as part of the [Antelope software suite](https://github.com/AntelopeIO/leap). To install `cleos` just visit the [Antelope Software Installation](../00_install/index.md) section.
`keosd` is distributed as part of the [EOSIO software suite](https://github.com/eosnetworkfoundation/mandel). To install `keosd` just visit the [EOSIO Software Installation](../00_install/index.md) section.
`keosd` is distributed as part of the [Antelope software suite](https://github.com/AntelopeIO/leap). To install `keosd` just visit the [Antelope Software Installation](../00_install/index.md) section.
## Operation
When a wallet is unlocked with the corresponding password, `cleos` can request `keosd` to sign a transaction with the appropriate private keys. Also, `keosd` provides support for hardware-based wallets such as Secure Encalve and YubiHSM.
[[info | Audience]]
| `keosd` is intended to be used by EOSIO developers only.
| `keosd` is intended to be used by Antelope developers only.
`eosio-blocklog` is a command-line interface (CLI) utility that allows node operators to perform low-level tasks on the block logs created by a `nodeos` instance. `eosio-blocklog` can perform one of the following operations:
* Convert a range of blocks to JSON format, as single objects or array.
* Generate `blocks.index` from `blocks.log` in blocks directory.
* Trim `blocks.log` and `blocks.index` between a range of blocks.
* Perform consistency test between `blocks.log` and `blocks.index`.
* Output the results of the operation to a file or `stdout` (default).
## Usage
```sh
eosio-blocklog <options> ...
```
## Options
Option (=default) | Description
-|-
`--blocks-dir arg (="blocks")` | The location of the blocks directory (absolute path or relative to the current directory)
`-o [ --output-file ] arg` | The file to write the generated output to (absolute or relative path). If not specified then output is to `stdout`
`-f [ --first ] arg (=0)` | The first block number to log or the first block to keep if `trim-blocklog` specified
`-l [ --last ] arg (=4294967295)` | the last block number to log or the last block to keep if `trim-blocklog` specified
`--no-pretty-print` | Do not pretty print the output. Useful if piping to `jq` to improve performance
`--as-json-array` | Print out JSON blocks wrapped in JSON array (otherwise the output is free-standing JSON objects)
`--make-index` | Create `blocks.index` from `blocks.log`. Must give `blocks-dir` location. Give `output-file` relative to current directory or absolute path (default is `<blocks-dir>/blocks.index`)
`--trim-blocklog` | Trim `blocks.log` and `blocks.index`. Must give `blocks-dir` and `first` and/or `last` options.
`--smoke-test` | Quick test that `blocks.log` and `blocks.index` are well formed and agree with each other
`-h [ --help ]` | Print this help message and exit
## Remarks
When `eosio-blocklog` is launched, the utility attempts to perform the specified operation, then yields the following possible outcomes:
* If successful, the selected operation is performed and the utility terminates with a zero error code (no error).
* If unsuccessful, the utility outputs an error to `stderr` and terminates with a non-zero error code (indicating an error).
This section contains documentation for additional utilities that complement or extend `nodeos` and potentially other EOSIO software:
This section contains documentation for additional utilities that complement or extend `nodeos` and potentially other Antelope software:
* [eosio-blocklog](eosio-blocklog.md) - Low-level utility for node operators to interact with block log files.
* [trace_api_util](trace_api_util.md) - Low-level utility for performing tasks associated with the [Trace API](../01_nodeos/03_plugins/trace_api_plugin/index.md).
EOSIO is the next-generation blockchain platform for creating and deploying smart contracts and distributed applications. EOSIO comes with a number of programs. The primary ones included in EOSIO are the following:
Antelope is the next-generation blockchain platform for creating and deploying smart contracts and distributed applications. Antelope comes with a number of programs. The primary ones included in Antelope are the following:
* [Nodeos](01_nodeos/index.md) - Core service daemon that runs a node for block production, API endpoints, or local development.
* [Cleos](02_cleos/index.md) - Command line interface to interact with the blockchain (via `nodeos`) and manage wallets (via `keosd`).
* [Keosd](03_keosd/index.md) - Component that manages EOSIO keys in wallets and provides a secure enclave for digital signing.
* [Keosd](03_keosd/index.md) - Component that manages Antelope keys in wallets and provides a secure enclave for digital signing.
The basic relationship between these components is illustrated in the diagram below.
Additional EOSIO Resources:
* [EOSIO Utilities](10_utilities/index.md) - Utilities that complement the EOSIO software.
Additional Antelope Resources:
* [Antelope Utilities](10_utilities/index.md) - Utilities that complement the Antelope software.
subjective_block_production_exceptionnew_exception(FC_LOG_MESSAGE(error,"Authorization failure with sent deferred transaction consisting only of actions to self"));
for(constauto&log:e.get_log()){
new_exception.append_log(log);
@@ -541,7 +541,7 @@ void apply_context::schedule_deferred_transaction( const uint128_t& sender_id, a
EOS_THROW(subjective_block_production_exception,"Unexpected exception occurred validating sent deferred transaction consisting only of actions to self");
}
}
@@ -553,12 +553,12 @@ void apply_context::schedule_deferred_transaction( const uint128_t& sender_id, a
booldisable_all_subjective_mitigations=false;//< for developer & testing purposes, can be configured using `disable-all-subjective-mitigations` when `EOSIO_DEVELOPER` build option is provided
uint32_tterminate_at_block=0;//< primarily for testing purposes
irreversible=0,///< this block has already been applied before by this node and is considered irreversible
validated=1,///< this is a complete block signed by a valid producer and has been previously applied by this node and therefore validated but it is not yet irreversible
complete=2,///< this is a complete block signed by a valid producer but is not yet irreversible nor has it yet been applied by this node
incomplete=3,///< this is an incomplete block (either being produced by a producer or speculatively produced by a node)
incomplete=3,///< this is an incomplete block being produced by a producer
ephemeral=4///< this is an incomplete block created for speculative execution of trxs, will always be aborted
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