C9S/coopenomics
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Alex Ant
2026-03-20 23:37:38 +05:00
parent 04281a2606
commit 49188d404e
232 changed files with 10551 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files
coopos/chain.swagger.yaml
+30 -1
View File
@@ -1,7 +1,7 @@
openapi: 3.0.0
info:
title: API цепи COOPOS
description: Спецификация Chain API узла COOPOS (nodeos, совместимый с EOSIO/Antelope). Подробности — в документации разработчика на https://coopenomics.world.
description: Спецификация Chain API узла COOPOS (nodeos). Подробности — в документации на https://coopenomics.world.
version: 1.0.0
license:
name: MIT
@@ -25,6 +25,7 @@ components:
paths:
/get_account:
post:
summary: Сведения об учётной записи
description: Возвращает объект с подробностями об указанной учётной записи в блокчейне.
operationId: get_account
requestBody:
@@ -47,6 +48,7 @@ paths:
$ref: "schemas/Account.yaml"
/get_block:
post:
summary: Получить блок
description: Возвращает объект с подробностями об указанном блоке блокчейна.
operationId: get_block
requestBody:
@@ -69,6 +71,7 @@ paths:
$ref: "schemas/Block.yaml"
/get_block_info:
post:
summary: Краткие сведения о блоке
description: Аналогично `get_block`, но возвращает фиксированный урезанный набор данных блока меньшего размера.
operationId: get_block_info
requestBody:
@@ -91,6 +94,7 @@ paths:
$ref: "schemas/BlockInfo.yaml"
/get_info:
post:
summary: Общие сведения о цепи
description: Возвращает объект с общими сведениями о блокчейне.
operationId: get_info
security: []
@@ -104,6 +108,7 @@ paths:
/push_transaction:
post:
summary: Применить транзакцию (push)
description: Ожидает транзакцию в формате JSON и пытается применить её к блокчейну.
operationId: push_transaction
requestBody:
@@ -136,6 +141,7 @@ paths:
/send_transaction:
post:
summary: Применить транзакцию (send)
description: Ожидает транзакцию в формате JSON и пытается применить её к блокчейну.
operationId: send_transaction
requestBody:
@@ -169,6 +175,7 @@ paths:
/push_transactions:
post:
summary: Применить несколько транзакций
description: Ожидает одну или несколько транзакций в формате JSON и пытается применить их к блокчейну.
operationId: push_transactions
requestBody:
@@ -188,6 +195,7 @@ paths:
/get_block_header_state:
post:
summary: Состояние заголовка блока
description: Возвращает состояние заголовка блока.
operationId: get_block_header_state
requestBody:
@@ -212,6 +220,7 @@ paths:
/get_abi:
post:
summary: ABI контракта
description: Возвращает ABI контракта по имени учётной записи.
operationId: get_abi
requestBody:
@@ -233,6 +242,7 @@ paths:
$ref: "schemas/Abi.yaml"
/get_currency_balance:
post:
summary: Баланс токена
description: Возвращает текущий баланс токена.
operationId: get_currency_balance
requestBody:
@@ -264,6 +274,7 @@ paths:
/get_currency_stats:
post:
summary: Статистика токена
description: Возвращает статистику по выпуску валюты (токена).
operationId: get_currency_stats
requestBody:
@@ -287,6 +298,7 @@ paths:
/get_required_keys:
post:
summary: Ключи для подписи транзакции
description: Возвращает ключи, необходимые для подписи транзакции.
operationId: get_required_keys
requestBody:
@@ -315,6 +327,7 @@ paths:
/get_producers:
post:
summary: Список продюсеров
description: Возвращает список продюсеров блокчейна.
operationId: get_producers
requestBody:
@@ -360,6 +373,7 @@ paths:
/get_raw_code_and_abi:
post:
summary: Сырой WASM и ABI
description: Возвращает сырой WASM и ABI контракта по имени учётной записи.
operationId: get_raw_code_and_abi
requestBody:
@@ -392,6 +406,7 @@ paths:
/get_scheduled_transactions:
post:
summary: Запланированные транзакции
description: Возвращает отложенные (запланированные) транзакции.
operationId: get_scheduled_transactions
requestBody:
@@ -424,6 +439,7 @@ paths:
/get_table_by_scope:
post:
summary: Области таблиц (scopes)
description: Возвращает области (scopes) таблиц контракта.
operationId: get_table_by_scope
requestBody:
@@ -476,6 +492,7 @@ paths:
/get_table_rows:
post:
summary: Строки таблицы состояния
description: Возвращает строки указанной таблицы состояния контракта.
operationId: get_table_rows
requestBody:
@@ -539,6 +556,7 @@ paths:
/get_code:
post:
summary: Код контракта (WASM)
description: Возвращает объект с WASM-кодом смарт-контракта.
operationId: get_code
requestBody:
@@ -578,6 +596,7 @@ paths:
/get_raw_abi:
post:
summary: Сырой ABI контракта
description: Возвращает объект с сырым ABI смарт-контракта.
operationId: get_raw_abi
requestBody:
@@ -611,6 +630,7 @@ paths:
/get_activated_protocol_features:
post:
summary: Активированные возможности протокола
description: Возвращает активированные на узле продюсера протокольные возможности.
operationId: get_activated_protocol_features
requestBody:
@@ -655,6 +675,7 @@ paths:
description: "Если активированных возможностей больше, чем limit, здесь порядковый номер следующей не вошедшей в ответ; иначе 0."
/get_accounts_by_authorizers:
post:
summary: Учётные записи по авторизующим
description: По набору имён учётных записей и публичных ключей находит разрешения (authorities), которые полностью или частично могут быть удовлетворены этими данными.
operationId: get_accounts_by_authorizers
requestBody:
@@ -715,6 +736,7 @@ paths:
description: Порог — сумма весов, которую нужно достичь или превысить
/get_transaction_status:
post:
summary: Статус транзакции (финальность)
description: Возвращает состояние цепи и при наличии — информацию о транзакции по её идентификатору. Требуется включённая функция статуса финальности транзакций в плагине chain (параметр nodeos `--transaction-finality-status-max-storage-size-gb`).
operationId: get_transaction_status
requestBody:
@@ -738,6 +760,7 @@ paths:
/send_transaction2:
post:
summary: Применить транзакцию (send v2)
description: |
Пытается применить транзакцию в формате JSON к блокчейну. Поддерживает полную трассировку неудачной транзакции и повторные попытки через nodeos, если они включены на узле. При включённом повторе API-узел досылает транзакцию в P2P-сеть до истечения срока, включения в блок или необратимости.
Внимание: по умолчанию вместо исключений возвращается полная трассировка ошибки. Не путайте наличие трассировки с успешным выполнением — проверяйте поля «receipt» и «except».
@@ -784,6 +807,7 @@ paths:
/compute_transaction:
post:
summary: Симуляция транзакции без записи
description: |
Выполняет указанную транзакцию, формирует трассировку (включая расход ресурсов), затем откатывает все изменения состояния; субъективный биллинг для аккаунта не увеличивается. Подписи, если есть, обрабатываются, ошибки подписи игнорируются. Неуспешные транзакции всё равно содержат трассировку сбоя.
Внимание: на публичных узлах с включённым compute_transaction нужно ограничивать частоту запросов (защита от DoS).
@@ -818,6 +842,7 @@ paths:
/get_code_hash:
post:
summary: Хеш кода контракта
description: Возвращает хеш кода смарт-контракта в блокчейне. Его можно сравнить с ожидаемым значением, чтобы убедиться, что код не менялся.
operationId: get_code_hash
requestBody:
@@ -846,6 +871,7 @@ paths:
/get_transaction_id:
post:
summary: Идентификатор транзакции
description: Возвращает идентификатор транзакции (хеш транзакции) для переданной транзакции.
operationId: get_transaction_id
requestBody:
@@ -865,6 +891,7 @@ paths:
/get_producer_schedule:
post:
summary: Расписание продюсеров
description: Возвращает текущее расписание продюсеров — активный список и порядок ротации.
operationId: get_producer_schedule
responses:
@@ -887,6 +914,7 @@ paths:
/send_read_only_transaction:
post:
summary: Транзакция только для чтения
description: Отправляет транзакцию только для чтения в формате JSON; она не предназначена для включения в блокчейн. Если транзакция меняет состояние цепи, узел отклонит её.
operationId: send_read_only_transaction
requestBody:
@@ -917,6 +945,7 @@ paths:
/push_block:
post:
summary: Передать блок в цепь
description: Передаёт блок в блокчейн (для специальных сценариев узла).
operationId: push_block
requestBody:
coopos/config.example.ini
+492
View File
@@ -0,0 +1,492 @@
# Percentage of cpu block production time used to produce block. Whole number percentages, e.g. 80 for 80% (eosio::producer_plugin)
# cpu-effort-percent = 80
# Percentage of cpu block production time used to produce last block. Whole number percentages, e.g. 80 for 80% (eosio::producer_plugin)
# last-block-cpu-effort-percent = 80
# the location of the blocks directory (absolute path or relative to application data dir) (eosio::chain_plugin)
# blocks-dir = "blocks"
# split the block log file when the head block number is the multiple of the stride
# When the stride is reached, the current block log and index will be renamed '<blocks-retained-dir>/blocks-<start num>-<end num>.log/index'
# and a new current block log and index will be created with the most recent block. All files following
# this format will be used to construct an extended block log. (eosio::chain_plugin)
# blocks-log-stride =
# the maximum number of blocks files to retain so that the blocks in those files can be queried.
# When the number is reached, the oldest block file would be moved to archive dir or deleted if the archive dir is empty.
# The retained block log files should not be manipulated by users. (eosio::chain_plugin)
# max-retained-block-files =
# the location of the blocks retained directory (absolute path or relative to blocks dir).
# If the value is empty, it is set to the value of blocks dir. (eosio::chain_plugin)
# blocks-retained-dir =
# the location of the blocks archive directory (absolute path or relative to blocks dir).
# If the value is empty, blocks files beyond the retained limit will be deleted.
# All files in the archive directory are completely under user's control, i.e. they won't be accessed by nodeos anymore. (eosio::chain_plugin)
# blocks-archive-dir =
# the location of the state directory (absolute path or relative to application data dir) (eosio::chain_plugin)
# state-dir = "state"
# the location of the protocol_features directory (absolute path or relative to application config dir) (eosio::chain_plugin)
# protocol-features-dir = "protocol_features"
# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints. (eosio::chain_plugin)
# checkpoint =
# Override default WASM runtime ( "eos-vm-jit", "eos-vm")
# "eos-vm-jit" : A WebAssembly runtime that compiles WebAssembly code to native x86 code prior to execution.
# "eos-vm" : A WebAssembly interpreter.
# (eosio::chain_plugin)
# wasm-runtime = eos-vm-jit
# The name of an account whose code will be profiled (eosio::chain_plugin)
# profile-account =
# Override default maximum ABI serialization time allowed in ms (eosio::chain_plugin)
# abi-serializer-max-time-ms = 15
# Maximum size (in MiB) of the chain state database (eosio::chain_plugin)
# chain-state-db-size-mb = 1024
# Safely shut down node when free space remaining in the chain state database drops below this size (in MiB). (eosio::chain_plugin)
# chain-state-db-guard-size-mb = 128
# Percentage of actual signature recovery cpu to bill. Whole number percentages, e.g. 50 for 50% (eosio::chain_plugin)
# signature-cpu-billable-pct = 50
# Number of worker threads in controller thread pool (eosio::chain_plugin)
# chain-threads = 2
# print contract's output to console (eosio::chain_plugin)
# contracts-console = false
# print deeper information about chain operations (eosio::chain_plugin)
deep-mind = false
# Account added to actor whitelist (may specify multiple times) (eosio::chain_plugin)
# actor-whitelist =
# Account added to actor blacklist (may specify multiple times) (eosio::chain_plugin)
# actor-blacklist =
# Contract account added to contract whitelist (may specify multiple times) (eosio::chain_plugin)
# contract-whitelist =
# Contract account added to contract blacklist (may specify multiple times) (eosio::chain_plugin)
# contract-blacklist =
# Action (in the form code::action) added to action blacklist (may specify multiple times) (eosio::chain_plugin)
# action-blacklist =
# Public key added to blacklist of keys that should not be included in authorities (may specify multiple times) (eosio::chain_plugin)
# key-blacklist =
# Deferred transactions sent by accounts in this list do not have any of the subjective whitelist/blacklist checks applied to them (may specify multiple times) (eosio::chain_plugin)
# sender-bypass-whiteblacklist =
# Database read mode ("head", "irreversible", "speculative").
# In "head" mode: database contains state changes up to the head block; transactions received by the node are relayed if valid.
# In "irreversible" mode: database contains state changes up to the last irreversible block; transactions received via the P2P network are not relayed and transactions cannot be pushed via the chain API.
# In "speculative" mode: database contains state changes by transactions in the blockchain up to the head block as well as some transactions not yet included in the blockchain; transactions received by the node are relayed if valid.
# (eosio::chain_plugin)
# read-mode = head
# Allow API transactions to be evaluated and relayed if valid. (eosio::chain_plugin)
api-accept-transactions = true
# Chain validation mode ("full" or "light").
# In "full" mode all incoming blocks will be fully validated.
# In "light" mode all incoming blocks headers will be fully validated; transactions in those validated blocks will be trusted
# (eosio::chain_plugin)
# validation-mode = full
# Disable the check which subjectively fails a transaction if a contract bills more RAM to another account within the context of a notification handler (i.e. when the receiver is not the code of the action). (eosio::chain_plugin)
# disable-ram-billing-notify-checks = false
# Subjectively limit the maximum length of variable components in a variable legnth signature to this size in bytes (eosio::chain_plugin)
# maximum-variable-signature-length = 16384
# Indicate a producer whose blocks headers signed by it will be fully validated, but transactions in those validated blocks will be trusted. (eosio::chain_plugin)
# trusted-producer =
# Database map mode ("mapped", "heap", or "locked").
# In "mapped" mode database is memory mapped as a file.
# In "heap" mode database is preloaded in to swappable memory and will use huge pages if available.
# In "locked" mode database is preloaded, locked in to memory, and will use huge pages if available.
# (eosio::chain_plugin)
# database-map-mode = mapped
# Maximum size (in MiB) of the EOS VM OC code cache (eosio::chain_plugin)
# eos-vm-oc-cache-size-mb = 1024
# Number of threads to use for EOS VM OC tier-up (eosio::chain_plugin)
# eos-vm-oc-compile-threads = 1
# Enable EOS VM OC tier-up runtime (eosio::chain_plugin)
# eos-vm-oc-enable = false
# enable queries to find accounts by various metadata. (eosio::chain_plugin)
# enable-account-queries = false
# maximum allowed size (in bytes) of an inline action for a nonprivileged account (eosio::chain_plugin)
# max-nonprivileged-inline-action-size = 4096
# Maximum size (in GiB) allowed to be allocated for the Transaction Retry feature. Setting above 0 enables this feature. (eosio::chain_plugin)
# transaction-retry-max-storage-size-gb =
# How often, in seconds, to resend an incoming transaction to network if not seen in a block.
# Needs to be at least twice as large as p2p-dedup-cache-expire-time-sec. (eosio::chain_plugin)
# transaction-retry-interval-sec = 20
# Maximum allowed transaction expiration for retry transactions, will retry transactions up to this value.
# Should be larger than transaction-retry-interval-sec. (eosio::chain_plugin)
# transaction-retry-max-expiration-sec = 120
# Maximum size (in GiB) allowed to be allocated for the Transaction Finality Status feature. Setting above 0 enables this feature. (eosio::chain_plugin)
# transaction-finality-status-max-storage-size-gb =
# Duration (in seconds) a successful transaction's Finality Status will remain available from being first identified. (eosio::chain_plugin)
# transaction-finality-status-success-duration-sec = 180
# Duration (in seconds) a failed transaction's Finality Status will remain available from being first identified. (eosio::chain_plugin)
# transaction-finality-status-failure-duration-sec = 180
# Log the state integrity hash on startup (eosio::chain_plugin)
# integrity-hash-on-start = false
# Log the state integrity hash on shutdown (eosio::chain_plugin)
# integrity-hash-on-stop = false
# If set to greater than 0, periodically prune the block log to store only configured number of most recent blocks.
# If set to 0, no blocks are be written to the block log; block log file is removed after startup. (eosio::chain_plugin)
# block-log-retain-blocks =
# The filename (relative to data-dir) to create a unix socket for HTTP RPC; set blank to disable. (eosio::http_plugin)
# unix-socket-path =
# The local IP and port to listen for incoming http connections; set blank to disable. (eosio::http_plugin)
# http-server-address = 127.0.0.1:8888
# Specify the Access-Control-Allow-Origin to be returned on each request (eosio::http_plugin)
# access-control-allow-origin =
# Specify the Access-Control-Allow-Headers to be returned on each request (eosio::http_plugin)
# access-control-allow-headers =
# Specify the Access-Control-Max-Age to be returned on each request. (eosio::http_plugin)
# access-control-max-age =
# Specify if Access-Control-Allow-Credentials: true should be returned on each request. (eosio::http_plugin)
# access-control-allow-credentials = false
# The maximum body size in bytes allowed for incoming RPC requests (eosio::http_plugin)
# max-body-size = 2097152
# Maximum size in megabytes http_plugin should use for processing http requests. -1 for unlimited. 429 error response when exceeded. (eosio::http_plugin)
# http-max-bytes-in-flight-mb = 500
# Maximum number of requests http_plugin should use for processing http requests. 429 error response when exceeded. (eosio::http_plugin)
# http-max-in-flight-requests = -1
# Maximum time for processing a request, -1 for unlimited (eosio::http_plugin)
# http-max-response-time-ms = 30
# Append the error log to HTTP responses (eosio::http_plugin)
# verbose-http-errors = false
# If set to false, then any incoming "Host" header is considered valid (eosio::http_plugin)
# http-validate-host = true
# Additionaly acceptable values for the "Host" header of incoming HTTP requests, can be specified multiple times. Includes http/s_server_address by default. (eosio::http_plugin)
# http-alias =
# Number of worker threads in http thread pool (eosio::http_plugin)
# http-threads = 2
# If set to false, do not keep HTTP connections alive, even if client requests. (eosio::http_plugin)
# http-keep-alive = true
# The actual host:port used to listen for incoming p2p connections. (eosio::net_plugin)
# p2p-listen-endpoint = 0.0.0.0:9876
# An externally accessible host:port for identifying this node. Defaults to p2p-listen-endpoint. (eosio::net_plugin)
# p2p-server-address =
# The public endpoint of a peer node to connect to. Use multiple p2p-peer-address options as needed to compose a network.
# Syntax: host:port[:<trx>|<blk>]
# The optional 'trx' and 'blk' indicates to node that only transactions 'trx' or blocks 'blk' should be sent. Examples:
# p2p.eos.io:9876
# p2p.trx.eos.io:9876:trx
# p2p.blk.eos.io:9876:blk
# (eosio::net_plugin)
# p2p-peer-address =
# Maximum number of client nodes from any single IP address (eosio::net_plugin)
# p2p-max-nodes-per-host = 1
# Allow transactions received over p2p network to be evaluated and relayed if valid. (eosio::net_plugin)
# p2p-accept-transactions = true
# The account and public p2p endpoint of a block producer node to automatically connect to when the it is in producer schedule proximity
# . Syntax: account,host:port
# Example,
# eosproducer1,p2p.eos.io:9876
# eosproducer2,p2p.trx.eos.io:9876:trx
# eosproducer3,p2p.blk.eos.io:9876:blk
# (eosio::net_plugin)
# p2p-auto-bp-peer =
# The name supplied to identify this node amongst the peers. (eosio::net_plugin)
# agent-name = EOS Test Agent
# Can be 'any' or 'producers' or 'specified' or 'none'. If 'specified', peer-key must be specified at least once. If only 'producers', peer-key is not required. 'producers' and 'specified' may be combined. (eosio::net_plugin)
# allowed-connection = any
# Optional public key of peer allowed to connect. May be used multiple times. (eosio::net_plugin)
# peer-key =
# Tuple of [PublicKey, WIF private key] (may specify multiple times) (eosio::net_plugin)
# peer-private-key =
# Maximum number of clients from which connections are accepted, use 0 for no limit (eosio::net_plugin)
# max-clients = 25
# number of seconds to wait before cleaning up dead connections (eosio::net_plugin)
# connection-cleanup-period = 30
# max connection cleanup time per cleanup call in milliseconds (eosio::net_plugin)
# max-cleanup-time-msec = 10
# Maximum time to track transaction for duplicate optimization (eosio::net_plugin)
# p2p-dedup-cache-expire-time-sec = 10
# Number of worker threads in net_plugin thread pool (eosio::net_plugin)
# net-threads = 4
# number of blocks to retrieve in a chunk from any individual peer during synchronization (eosio::net_plugin)
# sync-fetch-span = 100
# Enable experimental socket read watermark optimization (eosio::net_plugin)
# use-socket-read-watermark = false
# The string used to format peers when logging messages about them. Variables are escaped with ${<variable name>}.
# Available Variables:
# _name self-reported name
#
# _cid assigned connection id
#
# _id self-reported ID (64 hex characters)
#
# _sid first 8 characters of _peer.id
#
# _ip remote IP address of peer
#
# _port remote port number of peer
#
# _lip local IP address connected to peer
#
# _lport local port number connected to peer
#
# (eosio::net_plugin)
# peer-log-format = ["${_name}" - ${_cid} ${_ip}:${_port}]
# peer heartbeat keepalive message interval in milliseconds (eosio::net_plugin)
# p2p-keepalive-interval-ms = 10000
# Enable block production, even if the chain is stale. (eosio::producer_plugin)
# enable-stale-production = false
# Start this node in a state where production is paused (eosio::producer_plugin)
# pause-on-startup = false
# Limits the maximum time (in milliseconds) that is allowed a pushed transaction's code to execute before being considered invalid (eosio::producer_plugin)
# max-transaction-time = 30
# Limits the maximum age (in seconds) of the DPOS Irreversible Block for a chain this node will produce blocks on (use negative value to indicate unlimited) (eosio::producer_plugin)
# max-irreversible-block-age = -1
# ID of producer controlled by this node (e.g. inita; may specify multiple times) (eosio::producer_plugin)
# producer-name =
# Key=Value pairs in the form <public-key>=<provider-spec>
# Where:
# <public-key> is a string form of a valid COOPOS public key
#
# <provider-spec> is a string in the form <provider-type>:<data>
#
# <provider-type> is KEY, KEOSD, or SE
#
# KEY:<data> is a string form of a valid COOPOS private key which maps to the provided public key
#
# KEOSD:<data> is the URL where keosd is available and the approptiate wallet(s) are unlocked
#
# (eosio::producer_plugin)
# signature-provider = EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEY:5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
# account that can not access to extended CPU/NET virtual resources (eosio::producer_plugin)
# greylist-account =
# Limit (between 1 and 1000) on the multiple that CPU/NET virtual resources can extend during low usage (only enforced subjectively; use 1000 to not enforce any limit) (eosio::producer_plugin)
# greylist-limit = 1000
# Offset of non last block producing time in microseconds. Valid range 0 .. -block_time_interval. (eosio::producer_plugin)
# produce-time-offset-us = 0
# Offset of last block producing time in microseconds. Valid range 0 .. -block_time_interval. (eosio::producer_plugin)
# last-block-time-offset-us = -200000
# Percentage of cpu block production time used to produce block. Whole number percentages, e.g. 80 for 80% (eosio::producer_plugin)
# cpu-effort-percent = 10
# Percentage of cpu block production time used to produce last block. Whole number percentages, e.g. 80 for 80% (eosio::producer_plugin)
# last-block-cpu-effort-percent = 10
# Threshold of CPU block production to consider block full; when within threshold of max-block-cpu-usage block can be produced immediately (eosio::producer_plugin)
# max-block-cpu-usage-threshold-us = 5000
# Threshold of NET block production to consider block full; when within threshold of max-block-net-usage block can be produced immediately (eosio::producer_plugin)
# max-block-net-usage-threshold-bytes = 1024
# Maximum wall-clock time, in milliseconds, spent retiring scheduled transactions (and incoming transactions according to incoming-defer-ratio) in any block before returning to normal transaction processing. (eosio::producer_plugin)
# max-scheduled-transaction-time-per-block-ms = 100
# Time in microseconds allowed for a transaction that starts with insufficient CPU quota to complete and cover its CPU usage. (eosio::producer_plugin)
# subjective-cpu-leeway-us = 31000
# Sets the maximum amount of failures that are allowed for a given account per window size. (eosio::producer_plugin)
# subjective-account-max-failures = 3
# Sets the window size in number of blocks for subjective-account-max-failures. (eosio::producer_plugin)
# subjective-account-max-failures-window-size = 1
# Sets the time to return full subjective cpu for accounts (eosio::producer_plugin)
# subjective-account-decay-time-minutes = 1440
# ratio between incoming transactions and deferred transactions when both are queued for execution (eosio::producer_plugin)
# incoming-defer-ratio = 1
# Maximum size (in MiB) of the incoming transaction queue. Exceeding this value will subjectively drop transaction with resource exhaustion. (eosio::producer_plugin)
# incoming-transaction-queue-size-mb = 1024
# Disable subjective CPU billing for API/P2P transactions (eosio::producer_plugin)
# disable-subjective-billing = true
# Account which is excluded from subjective CPU billing (eosio::producer_plugin)
# disable-subjective-account-billing =
# Disable subjective CPU billing for P2P transactions (eosio::producer_plugin)
# disable-subjective-p2p-billing = true
# Disable subjective CPU billing for API transactions (eosio::producer_plugin)
# disable-subjective-api-billing = true
# Number of worker threads in producer thread pool (eosio::producer_plugin)
# producer-threads = 1
# the location of the snapshots directory (absolute path or relative to application data dir) (eosio::producer_plugin)
# snapshots-dir = "snapshots"
# Number of worker threads in read-only execution thread pool. Max 8. (eosio::producer_plugin)
# read-only-threads =
# Time in microseconds the write window lasts. (eosio::producer_plugin)
# read-only-write-window-time-us = 200000
# Time in microseconds the read window lasts. (eosio::producer_plugin)
# read-only-read-window-time-us = 60000
# The local IP and port to listen for incoming prometheus metrics http request. (eosio::prometheus_plugin)
# prometheus-exporter-address = 127.0.0.1:9101
# Time in seconds between two consecutive checks of resource usage. Should be between 1 and 300 (eosio::resource_monitor_plugin)
# resource-monitor-interval-seconds = 2
# Threshold in terms of percentage of used space vs total space. If used space is above (threshold - 5%), a warning is generated. Unless resource-monitor-not-shutdown-on-threshold-exceeded is enabled, a graceful shutdown is initiated if used space is above the threshold. The value should be between 6 and 99 (eosio::resource_monitor_plugin)
# resource-monitor-space-threshold = 90
# Absolute threshold in gibibytes of remaining space; applied to each monitored directory. If remaining space is less than value for any monitored directories then threshold is considered exceeded.Overrides resource-monitor-space-threshold value. (eosio::resource_monitor_plugin)
# resource-monitor-space-absolute-gb =
# Used to indicate nodeos will not shutdown when threshold is exceeded. (eosio::resource_monitor_plugin)
# resource-monitor-not-shutdown-on-threshold-exceeded =
# Number of resource monitor intervals between two consecutive warnings when the threshold is hit. Should be between 1 and 450 (eosio::resource_monitor_plugin)
# resource-monitor-warning-interval = 30
# Limits the maximum time (in milliseconds) that is allowed for sending requests to a keosd provider for signing (eosio::signature_provider_plugin)
# keosd-provider-timeout = 5
# the location of the state-history directory (absolute path or relative to application data dir) (eosio::state_history_plugin)
# state-history-dir = "state-history"
# the location of the state history retained directory (absolute path or relative to state-history dir). (eosio::state_history_plugin)
# state-history-retained-dir =
# the location of the state history archive directory (absolute path or relative to state-history dir).
# If the value is empty string, blocks files beyond the retained limit will be deleted.
# All files in the archive directory are completely under user's control, i.e. they won't be accessed by nodeos anymore. (eosio::state_history_plugin)
# state-history-archive-dir =
# split the state history log files when the block number is the multiple of the stride
# When the stride is reached, the current history log and index will be renamed '*-history-<start num>-<end num>.log/index'
# and a new current history log and index will be created with the most recent blocks. All files following
# this format will be used to construct an extended history log. (eosio::state_history_plugin)
# state-history-stride =
# the maximum number of history file groups to retain so that the blocks in those files can be queried.
# When the number is reached, the oldest history file would be moved to archive dir or deleted if the archive dir is empty.
# The retained history log files should not be manipulated by users. (eosio::state_history_plugin)
# max-retained-history-files =
# enable trace history (eosio::state_history_plugin)
# trace-history = false
# enable chain state history (eosio::state_history_plugin)
# chain-state-history = false
# the endpoint upon which to listen for incoming connections. Caution: only expose this port to your internal network. (eosio::state_history_plugin)
# state-history-endpoint = 127.0.0.1:8080
# the path (relative to data-dir) to create a unix socket upon which to listen for incoming connections. (eosio::state_history_plugin)
# state-history-unix-socket-path =
# enable debug mode for trace history (eosio::state_history_plugin)
# trace-history-debug-mode = false
# if set, periodically prune the state history files to store only configured number of most recent blocks (eosio::state_history_plugin)
# state-history-log-retain-blocks =
# the location of the trace directory (absolute path or relative to application data dir) (eosio::trace_api_plugin)
# trace-dir = "traces"
# the number of blocks each "slice" of trace data will contain on the filesystem (eosio::trace_api_plugin)
# trace-slice-stride = 10000
# Number of blocks to ensure are kept past LIB for retrieval before "slice" files can be automatically removed.
# A value of -1 indicates that automatic removal of "slice" files will be turned off. (eosio::trace_api_plugin)
# trace-minimum-irreversible-history-blocks = -1
# Number of blocks to ensure are uncompressed past LIB. Compressed "slice" files are still accessible but may carry a performance loss on retrieval
# A value of -1 indicates that automatic compression of "slice" files will be turned off. (eosio::trace_api_plugin)
# trace-minimum-uncompressed-irreversible-history-blocks = -1
# ABIs used when decoding trace RPC responses.
# There must be at least one ABI specified OR the flag trace-no-abis must be used.
# ABIs are specified as "Key=Value" pairs in the form <account-name>=<abi-def>
# Where <abi-def> can be:
# an absolute path to a file containing a valid JSON-encoded ABI
# a relative path from `data-dir` to a file containing a valid JSON-encoded ABI
# (eosio::trace_api_plugin)
# trace-rpc-abi =
# Use to indicate that the RPC responses will not use ABIs.
# Failure to specify this option when there are no trace-rpc-abi configuations will result in an Error.
# This option is mutually exclusive with trace-rpc-api (eosio::trace_api_plugin)
# trace-no-abis =
# Plugin(s) to enable, may be specified multiple times
# plugin =
coopos/producer.swagger.yaml
+1 -1
View File
@@ -10,7 +10,7 @@ info:
url: https://coopenomics.world
tags:
- name: Версия протокола 4.0
description: Тег релиза бинарников Leap совпадает с версией протокола
description: Тег релиза бинарников COOPOS совпадает с версией протокола
servers:
- url: "{protocol}://{host}:{port}/v1"
variables:
coopos/schemas/DateTime.yaml
+1 -1
View File
@@ -1,3 +1,3 @@
type: string
description: Дата и время истечения транзакции (строка в формате, принимаемом узлом COOPOS/EOSIO).
description: Дата и время истечения транзакции (строка в формате, принимаемом узлом COOPOS).
title: Дата и время
coopos/schemas/NamePrivileged.yaml
+1 -1
View File
@@ -1,4 +1,4 @@
type: string
pattern: '^[a-z1-5\.]{1,13}$'
description: Имя привилегированной учётной записи (подмножество правил имён EOSIO/COOPOS).
description: Имя привилегированной учётной записи (подмножество правил имён COOPOS).
title: Привилегированное имя
coopos/schemas/Symbol.yaml
+1 -1
View File
@@ -1,4 +1,4 @@
type: string
description: Строка актива EOSIO/COOPOS — дробная часть с точностью 4 и символ из 1–7 заглавных букв через пробел, например «1.0000 ABC».
description: Строка актива COOPOS — дробная часть с точностью 4 и символ из 1–7 заглавных букв через пробел, например «1.0000 ABC».
pattern: "^([0-9]{1,32}.[0-9]{4} [A-Z]{1,7})$"
title: Символ актива
docs/documentation.md
+5 -7
View File
@@ -17,10 +17,10 @@
---
Документация к блокчейн-протоколу EOSIO & ANTELOPE, который лежит в основе программного комплекса Цифрового Кошелька.
Документация по стеку **COOPOS** — узлам, API и инструментам блокчейна кооперативной экономики.
[:octicons-arrow-right-24: Подробнее](https://developers.eos.io)
[:octicons-arrow-right-24: Репозиторий](https://github.com/blockchain)
[:octicons-arrow-right-24: Блокчейн](documentation/blockchain/intro.md)
[:octicons-arrow-right-24: Программы узла](documentation/blockchain/coopos/index.md)
- __Смарт-контракты__
@@ -189,7 +189,7 @@ docker run --name node -d -p 8888:8888 -p 8080:8080 \-v $HOME/blockchain/data:/m
__Сборка из исходников__
Инструкция сборки из исходного кода описана в [репозитории](https://github.com/coopenomics/blockchain).
Инструкция сборки из исходного кода описана в [репозитории COOPOS](https://github.com/coopenomics/coopos).
@@ -260,11 +260,9 @@ const options = {
const session = new Session(args, options)
```
Теперь вы можете применять сформированную сессию для отправки транзакций в любые смарт-контракты системы. Для чтения же информации из таблиц блокчейна вам потребуется ApiClient:
Теперь вы можете применять сформированную сессию для отправки транзакций в любые смарт-контракты системы. Для чтения информации из таблиц блокчейна нужен клиент Chain API из [WharfKit](https://wharfkit.com) (класс `APIClient`, подключение по инструкции актуальной версии SDK):
```
import { APIClient } from "@wharfkit/antelope"
const client = new APIClient({
url: "https://testnet.coopenomics.world",
})
docs/documentation/blockchain/components.md
+1 -1
View File
@@ -1,4 +1,4 @@
Платформа кооперативной экономики основана на открытом исходном коде блокчейна EOSIO и Antelope.
Платформа кооперативной экономики использует стек **COOPOS**.
## nodeos
Ведущая программа, которая управляет хранением данных в блокчейне, поддерживает сетевые соединения, передаёт и принимает транзакции, воспроизводит состояние базы данных, исполняет действия, и так далее - т.е. выполняет всю базовую инфраструктурную работу платформы.
docs/documentation/blockchain/configuration/api-node.md
+53
View File
@@ -0,0 +1,53 @@
# Пример конфигурации: API-нода
**API-нода** обслуживает приложения: запросы к состоянию цепочки (`chain_api_plugin`), при необходимости сеть (`net_api_plugin`), иногда трассировку и историю состояния. Она **не подписывает блоки**, но часто принимает транзакции от клиентов и передаёт их в сеть.
## Зачем именно так
- **`chain_api_plugin` + `http_plugin`** — основа публичного или внутреннего RPC. Количество **`http-threads`** и размер **`chain-state-db-size-mb`** увеличивают по фактической нагрузке (число одновременных запросов, тяжёлые таблицы).
- **`api-accept-transactions = true`** — если узел должен принимать `push_transaction` / аналоги; если API только для чтения, можно выставить `false` и разгрузить узел.
- **`read-mode`**:
- **`head`** — данные до последнего полученного блока; удобно для «свежих» ответов.
- **`irreversible`** — только до последнего необратимого блока; строже согласованность, но в режиме `irreversible` транзакции из P2P не ретранслируются и поведение API для пуша может отличаться (см. комментарии в `config.example.ini` к `read-mode`).
- **`validation-mode = full`** — стандарт для узла, который следует за сетью.
- **P2P** — достаточно пиров для синхронизации; не обязательно держать сотни соединений, как на seed.
- **`net_api_plugin`** — включайте осознанно: он раскрывает информацию о P2P и часто **не выставляют публично**. Для внутренней диагностики — за VPN/firewall.
- **Защита HTTP**: `http-validate-host`, лимиты `http-max-in-flight-requests`, `http-max-bytes-in-flight-mb`, `max-body-size`, reverse proxy с rate limit и TLS на границе.
Опционально подключайте **`trace_api_plugin`** и **`state_history_plugin`**, если приложениям нужны трассировки действий или поток истории состояния (см. [State History (SHiP)](../state-history-ship.md)). **State-роль** (поставка истории по WebSocket) может жить **на этом же узле** или на отдельной [state-ноде](state-node.md) — совмещение с API удобно для малых контуров, разделение — для нагрузки и безопасности.
## Фрагмент `config.ini`
```ini
plugin = eosio::chain_plugin
plugin = eosio::net_plugin
plugin = eosio::http_plugin
plugin = eosio::chain_api_plugin
# Только защищённая внутренняя сеть:
# plugin = eosio::net_api_plugin
http-server-address = 0.0.0.0:8888
http-threads = 16
http-validate-host = true
http-max-in-flight-requests = 500
http-max-bytes-in-flight-mb = 256
max-body-size = 1048576
chain-threads = 8
chain-state-db-size-mb = 16384
chain-state-db-guard-size-mb = 256
validation-mode = full
read-mode = head
api-accept-transactions = true
p2p-listen-endpoint = 0.0.0.0:9876
p2p-peer-address = seed1.example.com:9876
p2p-peer-address = seed2.example.com:9876
max-clients = 50
net-threads = 4
# Нет producer-name / signature-provider
```
Для пользовательских доменов укажите **`access-control-allow-origin`** и связанные CORS-директивы только если это требуется браузерным клиентам; не используйте `*` на публичных эндпоинтах с чувствительными данными без понимания рисков.
docs/documentation/blockchain/configuration/index.md
+29
View File
@@ -0,0 +1,29 @@
# Конфигурация
Узел **COOPOS** настраивается как один процесс `nodeos`, набор **плагинов** и общий `config.ini`. От выбранных плагинов и значений ключевых директив зависит роль узла в сети.
Ниже — практические профили развёртывания. Подробнее о ролях узлов в архитектуре сети см. [Ноды и синхронизация истории](../nodes.md).
| Аспект | Seed-нода | Production-нода | API-нода | State-нода (история) | Light-нода |
|--------|------------|-----------------|----------|----------------------|------------|
| Назначение | Точка входа в P2P, «клей» топологии | Выпуск блоков (делегат/BP) | RPC для приложений | Поставка истории по **SHiP** | Быстрый старт **со снимка**, без полной истории |
| Плагины | `chain`, `net` | + `producer`, часто `http` | `chain`, `net`, `http`, `chain_api` (+ опц.) | + **`state_history`** | как правило `chain`, `net`, `http`, `chain_api` |
| Продюсирование | Нет | Да | Нет | Нет | Нет |
| HTTP API | Обычно выкл. или `127.0.0.1` | Локально / внутр. сеть | Публично или за proxy | Часто **совмещают** с API; можно только SHiP | Локальный/внутренний API кооператива |
| P2P | Много пиров | Узкий круг BP | Умеренно | Нужен для догона цепи | **Синхронизация между кооперативами** и с сетью |
| Особенности | — | Ключи продюсера | Нагрузка на RPC | Диск, защита WS SHiP | **`--snapshot`**, усечённый block log |
**State-нода** может быть **на том же хосте, что и API-нода**, или вынесена отдельно — см. [State-нода](state-node.md).
**Light-ноды** в системе кооперативов обычно сочетают **локальный API** и **P2P** между контурами; подробнее — [Light-нода](light-node.md).
## Дальше по разделу
- [Параметры](parameters.md) — справочник отдельных директив.
- [Seed-нода](seed-node.md)
- [Production-нода](production-node.md)
- [API-нода](api-node.md)
- [State-нода (история / SHiP)](state-node.md)
- [Light-нода](light-node.md)
Во всех примерах подставьте реальные хосты пиров, порты и пути к каталогам данных (`--data-dir`).
docs/documentation/blockchain/configuration/light-node.md
+52
View File
@@ -0,0 +1,52 @@
# Пример конфигурации: light-нода
**Light-нода** — узел COOPOS, поднятый **со снимком состояния (snapshot)** вместо полной перекачки и replay цепи с генезиса. У неё **нет полной истории блоков** с начала сети: есть **актуальное состояние** на момент снимка и дальнейшее наращивание цепи через **P2P** с момента подключения.
## Зачем именно так
- **Старт за минуты/часы вместо многодневной синхронизации** — критично для кооперативных и периферийных установок, где не нужен архив всей сети.
- **`--snapshot path/to.snapshot`** при запуске `nodeos` задаёт файл снимка; каталог данных и конфиг согласуют с инструкцией к вашему релизу COOPOS.
- **Журнал блоков** может быть пустым или коротким: узел не обязан хранить полный `blocks.log` от блока 1, если политика допускает усечённый лог (`block-log-retain-blocks` и см. [Параметры](parameters.md)).
- **P2P** остаётся обязательным: light-ноды **синхронизируют новые блоки** с сетью так же, как полные ноды, только **без истории «до снимка»**.
- **API** (`chain_api_plugin`) на light-ноде типичен для **локальной работы** приложений кооператива: чтение таблиц, отправка транзакций в сеть — в пределах доступного состояния и головы цепи.
## Кооперативы и light-ноды
В системе кооперативной экономики развёртывание часто строится вокруг **light-нод**: у каждого контура есть **свой узел** со снимком, **локальный Chain API** для сервисов и **P2P** для обмена блоками **между узлами кооперативов** (и с публичными seed/BP по политике сети). Полные архивные ноды и выделенные **state-ноды** остаются на уровне инфраструктуры сети или провайдеров; для **глубокой истории** приложения подключают **[Реактивный чтец SHiP](../../reactive-ship-reader.md)** к узлу с SHiP, а не полагаются на полный лог на каждой light-ноде.
## Фрагмент `config.ini`
Профиль по смыслу близок к [API-ноде](api-node.md), но эксплуатация отличается **запуском со снимка** и часто **меньшими лимитами диска** под блоки.
```ini
plugin = eosio::chain_plugin
plugin = eosio::net_plugin
plugin = eosio::http_plugin
plugin = eosio::chain_api_plugin
validation-mode = full
read-mode = head
http-server-address = 0.0.0.0:8888
http-threads = 8
api-accept-transactions = true
p2p-listen-endpoint = 0.0.0.0:9876
p2p-peer-address = peer-coop.example.com:9876
p2p-peer-address = seed-public.example.com:9876
chain-state-db-size-mb = 8192
# Опционально: усечённый block log, если не нужна длинная локальная история блоков
# block-log-retain-blocks = 100000
# Опционально: SHiP на light-ноде — только для диапазона, доступного узлу после снимка
# plugin = eosio::state_history_plugin
# trace-history = true
# chain-state-history = true
# state-history-endpoint = 127.0.0.1:8080
```
**Запуск (схематично):** `nodeos --config-dir ... --data-dir ... --snapshot /path/to/snapshot.bin`
Конкретные флаги и порядок инициализации см. в документации к вашей версии COOPOS; снимок должен быть **совместим** по версии протокола с бинарником узла.
docs/documentation/blockchain/configuration.md → docs/documentation/blockchain/configuration/parameters.md
+7 -4
View File
@@ -1,5 +1,8 @@
# Конфигурация
Каждый из описанных параметров можно настроить для оптимизации работы nodeos в зависимости от целей и условий эксплуатации. Настраивая эти параметры, можно существенно изменить поведение узла, его производительность, безопасность и отказоустойчивость. Все эти параметры, или некоторые из них, устанавливаются в файле config.ini или передаются в качестве аргументов при запуске nodeos.
# Параметры конфигурации
Каждый из описанных параметров можно настроить для оптимизации работы `nodeos` (COOPOS) в зависимости от целей и условий эксплуатации. Настраивая эти параметры, можно существенно изменить поведение узла, его производительность, безопасность и отказоустойчивость. Значения задаются в `config.ini` или аргументами при запуске.
Типовые сочетания параметров для **seed-**, **production-** и **API-** ноды приведены в разделе [Конфигурация](index.md). Полный закомментированный перечень опций с пояснениями на английском см. в репозитории: `coopos/config.example.ini`.
## cpu-effort-percent
@@ -36,7 +39,7 @@ state-dir указывает путь к директории, где храни
## protocol-features-dir
Параметр protocol-features-dir указывает путь к директории, где хранятся файлы с признаками протоколов. Этот параметр используется для хранения и управления признаками протоколов EOSIO.
Параметр protocol-features-dir указывает путь к директории, где хранятся файлы с признаками протоколов. Этот параметр используется для хранения и управления признаками протоколов COOPOS.
## checkpoint
@@ -312,7 +315,7 @@ producer-name задает идентификатор продюсера, кон
## signature-provider
Параметр signature-provider задает пары ключ-значение в формате <public-key>=<provider-spec>, где <provider-spec> определяет тип и данные провайдера для подписи транзакций. Например, KEY:<data> для приватного ключа EOSIO или KEOSD:<data> для URL-адреса, где доступен keosd.
Параметр signature-provider задает пары ключ-значение в формате <public-key>=<provider-spec>, где <provider-spec> определяет тип и данные провайдера для подписи транзакций. Например, KEY:<data> для приватного ключа в формате KEY или KEOSD:<data> для URL-адреса, где доступен keosd.
## greylist-account
docs/documentation/blockchain/configuration/production-node.md
+54
View File
@@ -0,0 +1,54 @@
# Пример конфигурации: production-нода
**Production-нода** (нода делегата / block producer) **подписывает блоки** от имени аккаунта из графика продюсеров. Это самый чувствительный с точки зрения безопасности профиль: компрометация `signature-provider` равна компрометации ключа продюсера.
## Зачем именно так
- **`producer_plugin` обязателен**; **`producer-name`** и **`signature-provider`** — минимальная пара для подписи блоков. На проде обычно используют `KEOSD:` или аппаратный провайдер, а не `KEY:` с приватным ключом в файле.
- **`pause-on-startup = true`** — после рестарта производство не начнётся, пока вы явно не возобновите его (защита от двойного выпуска при ошибках в инфраструктуре). Перед включением убедитесь, что цепочка синхронизирована и график корректен.
- **`enable-stale-production = false`** (по умолчанию) — не выпускать блоки, если цепочка считается устаревшей; снижает риск некорректного поведения при сетевых сбоях.
- **`api-accept-transactions = false`** — публичная «касса» транзакций не на BP; транзакции приходят по P2P от API- и других нод.
- **HTTP на `127.0.0.1`** — если `http_plugin` нужен только для локального `cleos`/мониторинга. Публичный RPC на продюсере обычно не нужен и увеличивает атакуемую поверхность.
- **P2P — узкий круг** — соединения с другими BP и доверенными relay; опции вроде `allowed-connection`, `peer-key` и `p2p-auto-bp-peer` помогают ограничить, кто может подключаться (см. комментарии в `coopos/config.example.ini`).
- **`validation-mode = full`** — полная проверка входящих блоков.
- **`read-mode = head`** — состояние до головы цепочки, что соответствует роли продюсера.
Тюнинг **`cpu-effort-percent`**, **`producer-threads`**, **`chain-threads`** зависит от железа и нагрузки сети; начните с значений из примера и корректируйте по метрикам.
## Фрагмент `config.ini`
```ini
plugin = eosio::chain_plugin
plugin = eosio::net_plugin
plugin = eosio::http_plugin
plugin = eosio::producer_plugin
producer-name = yourproducer
# Пример с keosd; в бою — безопасное хранилище ключей, не файл с KEY:
signature-provider = YOUR_BLOCK_SIGNING_PUBKEY=KEOSD:http://127.0.0.1:8900
pause-on-startup = true
enable-stale-production = false
validation-mode = full
read-mode = head
http-server-address = 127.0.0.1:8888
http-validate-host = true
api-accept-transactions = false
p2p-listen-endpoint = 0.0.0.0:9876
p2p-server-address = YOUR_BP_PUBLIC:9876
p2p-peer-address = peer-bp1.example.com:9876
p2p-peer-address = peer-bp2.example.com:9876
chain-threads = 4
producer-threads = 2
cpu-effort-percent = 80
last-block-cpu-effort-percent = 80
max-transaction-time = 30
keosd-provider-timeout = 5
```
Дополнительно настройте файрвол так, чтобы **P2P-порт** был доступен только нужным пирам, а не всему интернету, если политика сети это допускает.
docs/documentation/blockchain/configuration/seed-node.md
+43
View File
@@ -0,0 +1,43 @@
# Пример конфигурации: seed-нода
**Seed-нода** — это узел, который в первую очередь держит **устойчивые P2P-соединения** и помогает новым участникам сети найти пиров. Она не выпускает блоки и обычно **не обязана** отдавать публичный HTTP API. Подробнее о роли seed в топологии см. [Ноды и синхронизация истории](../nodes.md).
## Зачем именно так
- **Только `chain_plugin` и `net_plugin`** — цепочка синхронизируется и ретранслируется по P2P без лишних подсистем (продюсер, публичный RPC).
- **`p2p-listen-endpoint` на `0.0.0.0`** — приём входящих соединений от других нод; **`p2p-server-address`** должен отражать **достижимый снаружи** адрес:порт, иначе пиры не смогут корректно анонсировать ваш узел.
- **Несколько `p2p-peer-address`** — связность с остальной сетью; для seed критично не зависеть от одного пира.
- **`max-clients` выше типового** — seed рассчитан на большее число одновременных P2P-клиентов, чем «одиночная» нода.
- **`validation-mode = full`** — полная проверка блоков; для публичной инфраструктуры это базовая гигиена.
- **`api-accept-transactions = false`** — снижает поверхность атаки: узел не принимает произвольные транзакции через Chain API (если HTTP вообще включён).
- **`http-server-address = 127.0.0.1:8888` или пусто** — мониторинг/админка только локально; наружу seed обычно открывают только P2P-порт.
## Фрагмент `config.ini`
```ini
# --- Плагины: цепочка + сеть, без продюсера и без публичного API
plugin = eosio::chain_plugin
plugin = eosio::net_plugin
# --- P2P: слушаем на всех интерфейсах, анонсируем внешний адрес
p2p-listen-endpoint = 0.0.0.0:9876
p2p-server-address = YOUR_PUBLIC_HOSTNAME:9876
p2p-peer-address = seed-a.example.com:9876
p2p-peer-address = seed-b.example.com:9876
max-clients = 150
net-threads = 8
sync-fetch-span = 100
validation-mode = full
read-mode = head
# --- HTTP только для локального мониторинга (при необходимости отключите строку, оставив пустым)
http-server-address = 127.0.0.1:8888
api-accept-transactions = false
# Нет producer-name и signature-provider — блоки не подписываются на этом узле
```
При необходимости добавьте `resource_monitor_plugin` и `prometheus_plugin` (см. [Параметры](parameters.md)) для дискового мониторинга и метрик — для долгоживущей seed это полезно.
docs/documentation/blockchain/configuration/state-node.md
+58
View File
@@ -0,0 +1,58 @@
# Пример конфигурации: state-нода (история / SHiP)
**State-нода** в прикладном смысле — это узел, на котором включён **`state_history_plugin`**, чтобы **отдавать историю цепи потоком** (блоки, трассировки, дельты таблиц) по протоколу **State History (SHiP)**. Такой узел обычно называют близко к **HISTORY-ноде** в [обзоре ролей узлов](../nodes.md).
## Совмещение с API-нодой
Один и тот же процесс `nodeos` может одновременно:
- обслуживать **Chain API** (`chain_api_plugin` + `http_plugin`);
- вести **журналы SHiP** и слушать **WebSocket** на `state-history-endpoint`.
Это удобно для небольших установок: один хост и для `get_table_rows`, и для индексатора по SHiP. **Обязательным** совмещение не является: для изоляции нагрузки и безопасности часто выделяют **отдельную машину** только под историю (большой диск, ограниченный круг клиентов по сети), а HTTP API держат на других узлах.
## Зачем именно так
- **`state_history_plugin`** — без него нет SHiP-канала, только обычный RPC и при необходимости Trace API с файлов.
- **`trace-history`** и **`chain-state-history`** включают по потребности: для обозревателей и индексаторов чаще нужны **и трассы, и дельты**; только дельты уменьшают объём, если не нужны детальные трассы.
- **`state-history-endpoint`** — слушать на **127.0.0.1** или внутреннем интерфейсе; наружу — только через VPN/SSH-туннель или reverse proxy с ограничением доступа. Поток истории не должен быть публичным без жёсткой политики.
- **`chain_plugin` + `net_plugin`** — узел должен **догонять сеть** и применять блоки, иначе журнал SHiP неполный.
- Размер диска и опции **stride / retain / archive** (`state-history-stride`, `max-retained-history-files`, `state-history-archive-dir` и др.) задают политику хранения; для долгоживущей ноды см. [Параметры](parameters.md).
Индексаторы в экосистеме COOPOS могут использовать **[Реактивный чтец SHiP](../../reactive-ship-reader.md)** как готовый клиент к этому endpoint.
## Фрагмент `config.ini`
```ini
plugin = eosio::chain_plugin
plugin = eosio::net_plugin
plugin = eosio::http_plugin
plugin = eosio::chain_api_plugin
plugin = eosio::state_history_plugin
# Синхронизация с сетью
p2p-listen-endpoint = 0.0.0.0:9876
p2p-peer-address = seed1.example.com:9876
p2p-peer-address = seed2.example.com:9876
validation-mode = full
read-mode = head
# HTTP API — по желанию на этой же ноде; для только-SHIP можно оставить 127.0.0.1
http-server-address = 127.0.0.1:8888
api-accept-transactions = false
# SHiP: только внутренняя сеть
trace-history = true
chain-state-history = true
state-history-endpoint = 127.0.0.1:8080
# state-history-unix-socket-path = ship.sock
state-history-dir = state-history
# state-history-stride = ...
# max-retained-history-files = ...
# Нет producer-name / signature-provider
```
Подробнее по протоколу и эксплуатации: [State History (SHiP)](../state-history-ship.md).
docs/documentation/blockchain/coopos/00_install/01_build-from-source/00_build-unsupported-os.md
+58
View File
@@ -0,0 +1,58 @@
---
content_title: Сборка COOPOS из исходников на других Unix-системах
---
**Инструкции по сборке на неподдерживаемых ОС следует считать экспериментальными, предоставляются «как есть» (best effort) и могут быть неполными.**
**Предупреждение о параллельной компиляции (флаг `-j`)**: при сборке C/C++ часто используют `make -j $(nproc)` по числу ядер. Учтите: некоторые единицы компиляции (.cpp) в COOPOS очень тяжёлые и при компиляции могут потреблять почти 4 ГБ ОЗУ. Возможно, придётся снизить степень параллелизма в зависимости от объёма памяти на машине сборки, например вместо `make -j $(nproc)` запустить `make -j2`. Исчерпание памяти обычно (но не всегда) проявляется как падение компилятора.
В целом мы рекомендуем так называемую **pinned**-сборку: версии компилятора и Boost остаются одинаковыми между сборками разных версий COOPOS (COOPOS требует неизменности этих версий, иначе состояние нужно восстанавливать из переносимого снимка).
<details>
<summary>Инструкции по сборке на FreeBSD 13.1</summary>
Установите зависимости:
```
pkg update && pkg install \
git \
cmake \
curl \
boost-all \
python3 \
llvm11 \
pkgconf
```
и выполните сборку (в FreeBSD 13.1 по умолчанию llvm13 — передайте cmake опции clang11):
```
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_CXX_COMPILER=clang++11 -DCMAKE_C_COMPILER=clang11 -DCMAKE_BUILD_TYPE=Release ..
make -j $(nproc) package
```
</details>
### Запуск тестов
При сборке из исходников рекомендуется запускать как минимум «параллелизуемые» тесты. В этот набор по умолчанию не входят WASM spec tests — их можно добавить для большего покрытия, они тоже запускаются параллельно.
```
cd build
# «parallelizable tests»: минимальный набор, который стоит прогонять
ctest -j $(nproc) -LE _tests
# Дополнительно: WASM spec tests
ctest -j $(nproc) -L wasm_spec_tests
```
Другие тесты доступны и полезны, но они чувствительны к другому ПО на той же машине и могут **SIGKILL** другие запущенные экземпляры **nodeos**:
```
cd build
# Эти тесты нельзя гонять параллельно, но они рекомендованы
ctest -L "nonparallelizable_tests"
# Эти тесты нельзя гонять параллельно; выполняются долго
ctest -L "long_running_tests"
```
docs/documentation/blockchain/coopos/00_install/01_build-from-source/index.md
+20
View File
@@ -0,0 +1,20 @@
---
content_title: Сборка COOPOS из исходников
---
Ранее рекомендованные shell-скрипты для сборки удалены; процесс полностью управляется CMake. Собирающим из исходников нужно самостоятельно установить зависимости. Список зависимостей и рекомендуемая процедура сборки — в файле [`README.md`](https://github.com/coopenomics/coopos/blob/main/README.md). Там же — как эффективно запускать тесты.
### Использование DUNE
Вместо сборки из исходников можно использовать [DUNE](https://github.com/AntelopeIO/DUNE) — удобный старт в Docker на разных платформах.
### Сборка из исходников
COOPOS можно собрать и установить из исходников. Актуальные инструкции — [здесь](https://github.com/coopenomics/coopos/blob/main/README.md#build-and-install-from-source).
#### Сборка «pinned» (фиксированные версии компилятора и Boost)
Инструкции для pinned-сборки перенесены [сюда](https://github.com/coopenomics/coopos/blob/main/README.md#pinned-build). Перед сборкой полезно прочитать [предварительные требования](https://github.com/coopenomics/coopos/blob/main/README.md#prerequisites) и предупреждение о параллельной сборке с флагом `-j` [здесь](https://github.com/coopenomics/coopos/blob/main/README.md#step-3---build).
#### Ручная (не «pinned») сборка
Инструкции для unpinned-сборки — [здесь](https://github.com/coopenomics/coopos/blob/main/README.md#unpinned-build). Также см. [prerequisites](https://github.com/coopenomics/coopos/blob/main/README.md#prerequisites) и предупреждение о `-j` [здесь](https://github.com/coopenomics/coopos/blob/main/README.md#step-3---build).
### Запуск тестов
Описание доступных наборов тестов и способов запуска — [здесь](https://github.com/coopenomics/coopos/blob/main/README.md#test).
docs/documentation/blockchain/coopos/00_install/index.md
+28
View File
@@ -0,0 +1,28 @@
---
content_title: Установка ПО COOPOS
---
!!! note "Установка и сеть"
Рекомендуемый способ — **сборка COOPOS из исходников** (ниже). Конфигурация узлов в сети: [Конфигурация нод](../../configuration/index.md).
Лучший способ установить и использовать COOPOS — собрать его из исходников:
* [Сборка COOPOS из исходников](01_build-from-source/index.md)
## Поддерживаемые операционные системы
COOPOS в настоящее время поддерживает следующие ОС:
1. Ubuntu 22.04 Jammy
2. Ubuntu 20.04 Focal
!!! note "Примечание"
Сборка и установка COOPOS на других Unix-подобных системах теоретически возможны. На отдельной странице собрана полезная информация, но имейте в виду: это экспериментально и не поддерживается официально.
* [Сборка COOPOS на других Unix-системах](01_build-from-source/00_build-unsupported-os.md)
## Docker Utilities for Node Execution (D.U.N.E.)
Если у вас другая ОС или вы не хотите собирать COOPOS из исходников, можно попробовать набор утилит на Docker — D.U.N.E. — для быстрого знакомства с COOPOS и разработки контрактов.
* [DUNE (Docker Utilities for Node Execution)](https://github.com/AntelopeIO/DUNE)
docs/documentation/blockchain/coopos/01_nodeos/02_usage/00_nodeos-options.md
+35
View File
@@ -0,0 +1,35 @@
---
content_title: Опции nodeos
---
`nodeos` — приложение командной строки (CLI). Его можно запускать вручную из терминала или скриптом. Поведение в основном задаётся загруженными плагинами и их опциями. У `nodeos` два класса опций: *специфичные для nodeos* и *специфичные для плагинов*.
## Опции nodeos
Они нужны в основном для «хозяйственных» задач: каталог данных блокчейна, имя файла конфигурации `nodeos`, путь к конфигурации логирования и т.д. Ниже — фрагмент вывода `nodeos --help` со специфичными для `nodeos` опциями (опции плагинов для ясности опущены):
```console
Application Config Options:
--plugin arg Plugin(s) to enable, may be specified
multiple times
Application Command Line Options:
-h [ --help ] Print this help message and exit.
-v [ --version ] Print version information.
--full-version Print full version information.
--print-default-config Print default configuration template
-d [ --data-dir ] arg Directory containing program runtime
data
--config-dir arg Directory containing configuration
files such as config.ini
-c [ --config ] arg (=config.ini) Configuration file name relative to
config-dir
-l [ --logconf ] arg (=logging.json) Logging configuration file name/path
for library users
```
## Опции плагинов
Они управляют поведением плагинов `nodeos`. У каждой опции плагина уникальное имя, порядок в командной строке или `config.ini` произвольный. При указании опций плагина соответствующие плагины нужно включить через `--plugin`, иначе опции игнорируются.
Подробности по опциям плагинов — в разделе [Плагины](../03_plugins/index.md).
docs/documentation/blockchain/coopos/01_nodeos/02_usage/01_nodeos-configuration.md
+52
View File
@@ -0,0 +1,52 @@
---
content_title: Конфигурация nodeos
---
Опции плагинов задаются через аргументы CLI или файл `config.ini`. Опции, специфичные для `nodeos`, — только из командной строки. Полный список опций CLI и `config.ini` даёт `nodeos --help`, как показано выше.
У каждой опции в `config.ini` есть соответствие в CLI, но не наоборот: часть опций CLI в `config.ini` недоступна. Например, большинство опций плагинов, выполняющих действия при старте, в `config.ini` не задаются — в частности `--delete-state-history` у `state_history_plugin`.
Например, `--plugin eosio::chain_api_plugin` эквивалентно строке `plugin = eosio::chain_api_plugin` в `config.ini`.
## Расположение `config.ini`
По умолчанию на Linux `config.ini` находится в:
`~/.local/share/eosio/nodeos/config`
Свой файл конфигурации задаётся опцией `nodeos` `--config path/to/config.ini`.
## Пример nodeos
Типичный запуск производящего узла:
```sh
nodeos \
-e -p eosio \
--data-dir /users/mydir/eosio/data \
--config-dir /users/mydir/eosio/config \
--plugin eosio::producer_plugin \
--plugin eosio::chain_plugin \
--plugin eosio::http_plugin \
--plugin eosio::state_history_plugin \
--contracts-console \
--access-control-allow-origin='*' \
--http-validate-host=false \
--verbose-http-errors \
--state-history-dir /shpdata \
--trace-history \
--chain-state-history \
>> nodeos.log 2>&1 &
```
Команда выше запускает производящий узел:
* включает выпуск блоков (`-e`)
* задаёт имя продюсера `eosio` (`-p`)
* задаёт каталог данных блокчейна (`--data-dir`)
* задаёт каталог `config.ini` (`--config-dir`)
* подключает плагины `producer_plugin`, `chain_plugin`, `http_plugin`, `state_history_plugin` (`--plugin`)
* передаёт опции `chain_plugin` (`--contracts-console`)
* передаёт опции `http_plugin` (`--access-control-allow-origin`, `--http-validate-host`, `--verbose-http-errors`)
* передаёт опции state history (`--state-history-dir`, `--trace-history`, `--chain-state-history`)
* перенаправляет `stdout` и `stderr` в `nodeos.log`
* запускает процесс в фоне (`&`)
docs/documentation/blockchain/coopos/01_nodeos/02_usage/02_node-setups/00_producing-node.md
+96
View File
@@ -0,0 +1,96 @@
---
content_title: Настройка производящего узла
---
!!! note "Нужны системные контракты"
Инструкции предполагают запуск производящего узла в сети с **загруженными системными контрактами**. На чистом dev-узле с нативной функциональностью или без системных контрактов шаги могут не сработать.
Производящий **nodeos** в сети COOPOS подписывает и выпускает блоки; ниже — регистрация аккаунта как продюсера, `producer-name`, `signature-provider`, пиры и подключение `chain_plugin` / `producer_plugin`. Остальные возможности задаются [другими плагинами](../../03_plugins/index.md).
## Перед началом
* [Установка COOPOS](../../../00_install/index.md); в `PATH` — `nodeos`, `cleos`, `keosd`.
[//]: # ( THIS IS A COMMENT LINK BELOW IS BROKEN )
[//]: # ( If you built COOPOS using shell scripts, make sure to run the Install Script ../../../00_install/01_build-from-source/01_shell-scripts/03_install-COOPOS-binaries.md )
* [Опции nodeos](../../02_usage/00_nodeos-options.md) — по необходимости.
## Шаги
1. [Зарегистрировать аккаунт как продюсера](#1-register-your-account-as-a-producer)
2. [Задать имя продюсера](#2-set-producer-name)
3. [Настроить signature-provider продюсера](#3-set-the-producers-signature-provider)
4. [Задать список пиров](#4-define-a-peers-list)
5. [Подключить нужные плагины](#5-load-the-required-plugins)
### 1. Зарегистрировать аккаунт как продюсера {#1-register-your-account-as-a-producer}
Чтобы аккаунт мог быть продюсером, зарегистрируйте его:
```sh
cleos system regproducer accountname1 EOS1234534... http://producer.site Antarctica
```
### 2. Имя продюсера {#2-set-producer-name}
В `config.ini` задайте опцию `producer-name` на ваш аккаунт:
```console
# config.ini:
# ID of producer controlled by this node (e.g. inita; may specify multiple times) (eosio::producer_plugin)
producer-name = youraccount
```
### 3. Signature-provider продюсера {#3-set-the-producers-signature-provider}
Нужен закрытый ключ продюсера; открытый ключ должен входить в authority аккаунта продюсера.
`signature-provider` задаётся кортежем из трёх полей:
* `public-key` — валидный открытый ключ COOPOS в виде строки.
* `provider-spec` — строка вида `<provider-type>:<data>`
* `provider-type` — KEY или KEOSD
#### Через KEY:
```console
# config.ini:
signature-provider = PUBLIC_SIGNING_KEY=KEY:PRIVATE_SIGNING_KEY
//Example
//signature-provider = EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEY:5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
```
#### Через keosd:
Можно использовать `keosd` вместо явного указания ключей.
```console
# config.ini:
signature-provider = KEOSD:<data>
//Example
//EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEOSD:https://127.0.0.1:88888
```
### 4. Список пиров {#4-define-a-peers-list}
```console
# config.ini:
# Default p2p port is 9876
p2p-peer-address = 123.255.78.9:9876
```
### 5. Нужные плагины {#5-load-the-required-plugins}
В [config.ini](../index.md) убедитесь, что подключены следующие плагины (или добавьте их):
```console
# config.ini:
plugin = eosio::chain_plugin
plugin = eosio::producer_plugin
```
docs/documentation/blockchain/coopos/01_nodeos/02_usage/02_node-setups/01_non-producing-node.md
+39
View File
@@ -0,0 +1,39 @@
---
content_title: Настройка непроизводящего узла
---
Непроизводящий **nodeos** в COOPOS только синхронизируется с пирами и не подписывает блоки; RPC, историю состояния и прочее включают [плагины](../../03_plugins/index.md) (кроме `producer_plugin`).
## Перед началом
* [Установка COOPOS](../../../00_install/index.md); в `PATH` — `nodeos`, `cleos`, `keosd`.
[//]: # ( THIS IS A COMMENT NEXT LINK CONTAINS A BROKEN LINK )
[//]: # ( If you built COOPOS using shell scripts, make sure to run the Install Script ../../../00_install/01_build-from-source/01_shell-scripts/03_install-COOPOS-binaries.md )
* [Опции nodeos](../../02_usage/00_nodeos-options.md) — по необходимости.
## Шаги
1. [Задать пиров](#1-set-peers)
2. [Включить один или несколько плагинов](#2-enable-one-or-more-available-plugins)
### 1. Пиры {#1-set-peers}
Укажите пиров в `config.ini`, например:
```console
# config.ini:
p2p-peer-address = 106.10.42.238:9876
```
Либо задайте пир при запуске `nodeos`:
```sh
nodeos ... --p2p-peer-address=106.10.42.238:9876
```
### 2. Плагины {#2-enable-one-or-more-available-plugins}
Список — [Плагины nodeos](../../03_plugins/index.md). Например: [`state_history_plugin`](../../03_plugins/state_history_plugin/index.md) для полной истории, [`http_plugin`](../../03_plugins/http_plugin/index.md) для HTTP RPC. У плагинов бывают зависимости — их нужно подключить вместе с ними.
docs/documentation/blockchain/coopos/01_nodeos/02_usage/02_node-setups/index.md
+12
View File
@@ -0,0 +1,12 @@
---
content_title: Типовые схемы узлов nodeos
---
`nodeos` обычно работает в двух режимах:
* [Производящий узел](00_producing-node.md)
* [Непроизводящий узел](01_non-producing-node.md)
**Производящие узлы** настроены на выпуск блоков. Они подключаются к P2P-сети и активно создают новые блоки. Свободные транзакции также проверяются и ретранслируются. В mainnet производящий узел выпускает блоки только если назначенный ему продюсер входит в активное расписание.
**Непроизводящие узлы** подключаются к P2P, но сами блоки не выпускают; их используют как прокси, для ретрансляции API-запросов, проверки транзакций, распространения данных между узлами и т.д. Также они удобны для мониторинга состояния цепочки.
docs/documentation/blockchain/coopos/01_nodeos/02_usage/03_development-environment/00_local-single-node-testnet.md
+119
View File
@@ -0,0 +1,119 @@
---
content_title: Локальная одноузловая тестовая сеть
---
На одной машине поднимается один производящий **nodeos** COOPOS (**single host, single-node testnet**). `cleos` вызывает действия в цепи и при необходимости сам поднимает `keosd`; отдельный `keosd` нужен, если держите кошелёк на фиксированном URL.
![Single host single node testnet](single-host-single-node-testnet.png)
## Перед началом
* [Установка COOPOS](../../../00_install/index.md); в `PATH` — `nodeos`, `cleos`, `keosd`.
[//]: # (THIS IS A COMMENT, NEXT LINK HAS BROKEN LINK)
[//]: # (If you built COOPOS using shell scripts, make sure to run the Install Script ../../../00_install/01_build-from-source/01_shell-scripts/03_install-COOPOS-binaries.md .)
* [Опции nodeos](../../02_usage/00_nodeos-options.md) — по необходимости.
## Шаги
Откройте одно окно терминала:
1. [Запустить производящий узел](#1-start-the-producer-node)
2. [Получить информацию об узле](#2-get-node-info)
### 1. Запуск производящего узла {#1-start-the-producer-node}
Одна команда для одноузлового блокчейна:
```sh
nodeos -e -p eosio --plugin eosio::chain_api_plugin --plugin eosio::history_api_plugin
```
!!! note "Минимальная конфигурация nodeos"
Минимально для выпуска блоков нужны `chain_api_plugin` и `history_api_plugin`, флаги `-e` (stale production) и `-p eosio` (имя продюсера `eosio`). Альтернатива — свой аккаунт в роли продюсера.
После запуска `nodeos` в логе должны появиться сообщения о выпуске блоков.
```console
1575001ms thread-0 chain_controller.cpp:235 _push_block ] initm #1 @2017-09-04T04:26:15 | 0 trx, 0 pending, exectime_ms=0
1575001ms thread-0 producer_plugin.cpp:207 block_production_loo ] initm generated block #1 @ 2017-09-04T04:26:15 with 0 trxs 0 pending
1578001ms thread-0 chain_controller.cpp:235 _push_block ] initc #2 @2017-09-04T04:26:18 | 0 trx, 0 pending, exectime_ms=0
1578001ms thread-0 producer_plugin.cpp:207 block_production_loo ] initc generated block #2 @ 2017-09-04T04:26:18 with 0 trxs 0 pending
...
eosio generated block 046b9984... #101527 @ 2018-04-01T14:24:58.000 with 0 trxs
eosio generated block 5e527ee2... #101528 @ 2018-04-01T14:24:58.500 with 0 trxs
...
```
На этом этапе `nodeos` работает с одним продюсером — `eosio`.
### 2. Информация об узле {#2-get-node-info}
```sh
cleos get info
```
Пример ответа:
```json
{
"server_version": "0f9df63e",
"chain_id": "cf057bbfb72640471fd910bcb67639c22df9f92470936cddc1ade0e2f2e7dc4f",
"head_block_num": 134,
"last_irreversible_block_num": 133,
"last_irreversible_block_id": "00000085060e9872849ef87bef3b19ab07de9faaed71154510c7f0aeeaddae2c",
"head_block_id": "000000861e3222dce1c7c2cfb938940d8aac22c816cc8b0b89f6bf65a8ad5bdc",
"head_block_time": "2019-11-18T22:13:10.500",
"head_block_producer": "eosio",
"virtual_block_cpu_limit": 228396,
"virtual_block_net_limit": 1197744,
"block_cpu_limit": 199900,
"block_net_limit": 1048576,
"server_version_string": "v2.0.0-rc2",
"fork_db_head_block_num": 134,
"fork_db_head_block_id": "000000861e3222dce1c7c2cfb938940d8aac22c816cc8b0b89f6bf65a8ad5bdc",
"server_full_version_string": "v2.0.0-rc2-0f9df63e1eca4dda4cb7df30683f4a1220599444"
}
```
## Дополнительные шаги
Продвинутым пользователям часто нужна своя конфигурация. У `nodeos` отдельный каталог конфигурации; путь зависит от ОС.
* macOS: `~/Library/Application\ Support/eosio/nodeos/config`
* Linux: `~/.local/share/eosio/nodeos/config`
При сборке в каталог кладётся типовой `genesis.json`. Свой каталог конфигурации задаётся `--config-dir`; при его использовании `genesis.json` нужно скопировать вручную.
Для осмысленной работы нужен корректный `config.ini`. При старте `nodeos` ищет `config.ini` в каталоге конфигурации; если файла нет, создаётся по умолчанию. Если готового `config.ini` нет, запустите `nodeos` и сразу остановите <kbd>Ctrl-C</kbd> — появится файл по умолчанию. Отредактируйте `config.ini`, добавив или изменив:
```console
# config.ini:
# Enable production on a stale chain, since a single-node test chain is pretty much always stale
enable-stale-production = true
# Enable block production with the testnet producers
producer-name = eosio
# Load the block producer plugin, so you can produce blocks
plugin = eosio::producer_plugin
# As well as API and HTTP plugins
plugin = eosio::chain_api_plugin
plugin = eosio::http_plugin
plugin = eosio::history_api_plugin
```
Затем снова запустите `nodeos`:
```sh
nodeos
```
Данные времени выполнения (shared memory, логи и т.д.) лежат в каталоге данных:
* macOS: `~/Library/Application\ Support/eosio/nodeos/data`
* Linux: `~/.local/share/eosio/nodeos/data`
Каталог данных задаётся `--data-dir`.
!!! note "Дальше"
Далее — [локальная многоузловая тестовая сеть на одном хосте](01_local-multi-node-testnet.md).
docs/documentation/blockchain/coopos/01_nodeos/02_usage/03_development-environment/01_local-multi-node-testnet.md
+209
View File
@@ -0,0 +1,209 @@
---
content_title: Локальная многоузловая тестовая сеть
---
Два производящих **nodeos** на одном хосте (**single host, multi-node testnet**): отдельные порты HTTP/P2P и каталоги `config`/`data`, связь через `cleos` и при необходимости `keosd`. Схема ниже.
![Single host multi node testnet](single-host-multi-node-testnet.png)
## Перед началом
* [Установка COOPOS](../../../00_install/index.md); в `PATH` — `nodeos`, `cleos`, `keosd`.
* [Опции nodeos](../../02_usage/00_nodeos-options.md) — по необходимости.
## Шаги
Откройте четыре окна терминала.
1. [Запустить менеджер кошельков](#1-start-the-wallet-manager)
2. [Создать кошелёк по умолчанию](#2-create-a-default-wallet)
3. [Импортировать ключ COOPOS](#3-loading-the-COOPOS-key)
4. [Запустить первый производящий узел](#4-start-the-first-producer-node)
5. [Запустить второй производящий узел](#5-start-the-second-producer-node)
6. [Получить информацию об узлах](#6-get-nodes-info)
### 1. Менеджер кошельков {#1-start-the-wallet-manager}
В первом терминале запустите `keosd`:
```sh
keosd --http-server-address 127.0.0.1:8899
```
При успехе в начале вывода будут строки вроде:
```console
2493323ms thread-0 wallet_plugin.cpp:39 plugin_initialize ] initializing wallet plugin
2493323ms thread-0 http_plugin.cpp:141 plugin_initialize ] host: 127.0.0.1 port: 8899
2493323ms thread-0 http_plugin.cpp:144 plugin_initialize ] configured http to listen on 127.0.0.1:8899
2493323ms thread-0 http_plugin.cpp:213 plugin_startup ] start listening for http requests
2493324ms thread-0 wallet_api_plugin.cpp:70 plugin_startup ] starting wallet_api_plugin
```
В логе должна появиться строка про `127.0.0.1:8899`; иначе смотрите ошибку и перезапустите `keosd`. Окно с `keosd` не закрывайте — переходите ко второму терминалу.
### 2. Кошелёк по умолчанию {#2-create-a-default-wallet}
Во втором терминале создайте кошелёк через `cleos`:
```sh
cleos --wallet-url http://127.0.0.1:8899 wallet create --to-console
```
`cleos` сообщит о создании кошелька `default` и выдаст пароль — сохраните его. Пример вывода:
```console
Creating wallet: default
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
"PW5JsmfYz2wrdUEotTzBamUCAunAA8TeRZGT57Ce6PkvM12tre8Sm"
```
В окне `keosd` появятся служебные сообщения. Дальнейшие команды `cleos` выполняйте во втором терминале.
### 3. Ключ COOPOS {#3-loading-the-COOPOS-key}
Приватная тестовая цепочка создаётся с типовым начальным ключом — его нужно импортировать в кошелёк.
```sh
cleos --wallet-url http://127.0.0.1:8899 wallet import --private-key 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
```
```console
imported private key for: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
```
### 4. Первый производящий узел {#4-start-the-first-producer-node}
В третьем терминале:
```sh
nodeos --enable-stale-production --producer-name eosio --plugin eosio::chain_api_plugin --plugin eosio::net_api_plugin
```
Получается специальный «bios»-продюсер. При успехе в логе `nodeos` виден выпуск блоков.
### 5. Второй производящий узел {#5-start-the-second-producer-node}
[//]: # (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 COOPOS binaries.)
Загрузите на `eosio` контракт `eosio.bios` (ресурсы аккаунтов и привилегированные вызовы). Во втором терминале:
```sh
cleos --wallet-url http://127.0.0.1:8899 set contract eosio build/contracts/eosio.bios
```
Создайте аккаунт-продюсер `inita`: сгенерируйте ключи и импортируйте закрытый в кошелёк.
```sh
cleos create key
```
!!! warning "Внимание"
Дальнейшие команды используют пары ключей из примера ниже. Чтобы копировать команды без правок, возьмите именно эти ключи, а не результат своей команды `cleos create key`. Если используете свои ключи — подставьте их во все следующие команды.
Типичный вывод `cleos create key`:
```console
Private key: 5JgbL2ZnoEAhTudReWH1RnMuQS6DBeLZt4ucV6t8aymVEuYg7sr
Public key: EOS6hMjoWRF2L8x9YpeqtUEcsDKAyxSuM1APicxgRU1E3oyV5sDEg
```
Импорт закрытого ключа:
```sh
cleos --wallet-url http://127.0.0.1:8899 wallet import 5JgbL2ZnoEAhTudReWH1RnMuQS6DBeLZt4ucV6t8aymVEuYg7sr
```
```console
imported private key for: EOS6hMjoWRF2L8x9YpeqtUEcsDKAyxSuM1APicxgRU1E3oyV5sDEg
```
Создание аккаунта `inita`: для `create account` нужны два открытых ключа — owner и active; здесь один и тот же ключ используется дважды.
```sh
cleos --wallet-url http://127.0.0.1:8899 create account eosio inita EOS6hMjoWRF2L8x9YpeqtUEcsDKAyxSuM1APicxgRU1E3oyV5sDEg EOS6hMjoWRF2L8x9YpeqtUEcsDKAyxSuM1APicxgRU1E3oyV5sDEg
```
```console
executed transaction: d1ea511977803d2d88f46deb554f5b6cce355b9cc3174bec0da45fc16fe9d5f3 352 bytes 102400 cycles
# eosio <= eosio::newaccount {"creator":"eosio","name":"inita","owner":{"threshold":1,"keys":[{"key":"EOS6hMjoWRF2L8x9YpeqtUEcsDKA...
```
Аккаунт готов; в других руководствах на него вешают контракты — здесь он станет продюсером блоков.
В четвёртом терминале запустите второй экземпляр `nodeos`. Командная строка длиннее, чтобы не конфликтовать с первым узлом. Можно скопировать команду и при необходимости поправить ключи:
```sh
nodeos --producer-name inita --plugin eosio::chain_api_plugin --plugin eosio::net_api_plugin --http-server-address 127.0.0.1:8889 --p2p-listen-endpoint 127.0.0.1:9877 --p2p-peer-address 127.0.0.1:9876 --config-dir node2 --data-dir node2 --signature-provider EOS6hMjoWRF2L8x9YpeqtUEcsDKAyxSuM1APicxgRU1E3oyV5sDEg=KEY:5JgbL2ZnoEAhTudReWH1RnMuQS6DBeLZt4ucV6t8aymVEuYg7sr
```
У нового узла в логе будет немного активности, затем тишина до последнего шага — пока `inita` не зарегистрирован как продюсер. Ниже пример хвоста лога (у вас могут отличаться времена):
```console
2393147ms thread-0 producer_plugin.cpp:176 plugin_startup ] producer plugin: plugin_startup() end
2393157ms thread-0 net_plugin.cpp:1271 start_sync ] Catching up with chain, our last req is 0, theirs is 8249 peer dhcp15.ociweb.com:9876 - 295f5fd
2393158ms thread-0 chain_controller.cpp:1402 validate_block_heade ] head_block_time 2018-03-01T12:00:00.000, next_block 2018-04-05T22:31:08.500, block_interval 500
2393158ms thread-0 chain_controller.cpp:1404 validate_block_heade ] Did not produce block within block_interval 500ms, took 3061868500ms)
2393512ms thread-0 producer_plugin.cpp:241 block_production_loo ] Not producing block because production is disabled until we receive a recent block (see: --enable-stale-production)
2395680ms thread-0 net_plugin.cpp:1385 recv_notice ] sync_manager got last irreversible block notice
2395680ms thread-0 net_plugin.cpp:1271 start_sync ] Catching up with chain, our last req is 8248, theirs is 8255 peer dhcp15.ociweb.com:9876 - 295f5fd
2396002ms thread-0 producer_plugin.cpp:226 block_production_loo ] Previous result occurred 5 times
2396002ms thread-0 producer_plugin.cpp:244 block_production_loo ] Not producing block because it isn't my turn, its eosio
```
Сейчас второй `nodeos` — «простаивающий» продюсер. Чтобы он стал активным, зарегистрируйте `inita` у bios-узла и обновите расписание продюсеров:
```sh
cleos --wallet-url http://127.0.0.1:8899 push action eosio setprods "{ \"schedule\": [{\"producer_name\": \"inita\",\"block_signing_key\": \"EOS6hMjoWRF2L8x9YpeqtUEcsDKAyxSuM1APicxgRU1E3oyV5sDEg\"}]}" -p eosio@active
```
```console
executed transaction: 2cff4d96814752aefaf9908a7650e867dab74af02253ae7d34672abb9c58235a 272 bytes 105472 cycles
# eosio <= eosio::setprods {"version":1,"producers":[{"producer_name":"inita","block_signing_key":"EOS6hMjoWRF2L8x9YpeqtUEcsDKA...
```
Двухузловая тестовая сеть готова. Исходный узел перестаёт выпускать блоки, но продолжает их получать. Проверьте `get info` на каждом узле.
### 6. Информация об узлах {#6-get-nodes-info}
Первый узел:
```sh
cleos get info
```
Пример ответа:
```json
{
"server_version": "223565e8",
"head_block_num": 11412,
"last_irreversible_block_num": 11411,
"head_block_id": "00002c94daf7dff456cd940bd585c4d9b38e520e356d295d3531144329c8b6c3",
"head_block_time": "2018-04-06T00:06:14",
"head_block_producer": "inita"
}
```
Второй узел:
```sh
cleos --url http://127.0.0.1:8889 get info
```
Пример ответа:
```json
{
"server_version": "223565e8",
"head_block_num": 11438,
"last_irreversible_block_num": 11437,
"head_block_id": "00002cae32697444fa9a2964e4db85b5e8fd4c8b51529a0c13e38587c1bf3c6f",
"head_block_time": "2018-04-06T00:06:27",
"head_block_producer": "inita"
}
```
Сеть на нескольких физических хостах настраивается отдельно.
docs/documentation/blockchain/coopos/01_nodeos/02_usage/03_development-environment/index.md
+30
View File
@@ -0,0 +1,30 @@
---
content_title: Среда разработки
---
Среду `nodeos` для разработки и тестов можно собрать по-разному; выбор зависит от целей проекта. Ниже — практичные варианты.
## Локальная одноузловая тестовая сеть
Подходит разработчикам смарт-контрактов, будущим продюсерам и операторам непроизводящих узлов. Минимальная конфигурация и мало требований.
* [Настроить nodeos как локальную одноузловую тестовую сеть](00_local-single-node-testnet.md)
## Локальная многоузловая тестовая сеть
Технически пригодна и для разработки контрактов, но часто избыточна. Полезна при работе с ядром: бенчмарки, оптимизация, эксперименты; также для обучения и проверки идей.
* [Настроить nodeos как локальную двухузловую тестовую сеть](01_local-multi-node-testnet.md)
* [Настроить nodeos как локальную 21-узловую тестовую сеть](/tutorials/bios-boot-tutorial.md)
## Официальный тестовый узел
Для простого старта и кроссплатформенности можно использовать инструменты вроде [DUNE](https://github.com/AntelopeIO/DUNE) (Docker) либо следовать [инструкциям в репозитории COOPOS](https://github.com/coopenomics/coopos).
## Сторонние тестовые сети
Для тестирования dApp и контрактов COOPOS доступны сторонние тестнеты:
* Jungle Testnet: [монитор](https://monitor.jungletestnet.io/), [сайт](https://jungletestnet.io/)
* [CryptoKylin Testnet](https://www.cryptokylin.io/)
* [Telos Testnet](https://mon-test.telosfoundation.io/)
docs/documentation/blockchain/coopos/01_nodeos/02_usage/03_development-environment/single-host-multi-node-testnet.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 208 KiB

docs/documentation/blockchain/coopos/01_nodeos/02_usage/03_development-environment/single-host-single-node-testnet.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 178 KiB

docs/documentation/blockchain/coopos/01_nodeos/02_usage/index.md
+10
View File
@@ -0,0 +1,10 @@
---
content_title: Использование nodeos
---
Здесь описано, как пользоваться `nodeos`, перечислены опции конфигурации, раскладка файлов на диске, типовые конфигурации узлов и варианты тестовой среды для разработки.
* [Опции](00_nodeos-options.md) — запуск `nodeos`; опции самого `nodeos` и плагинов.
* [Конфигурация](01_nodeos-configuration.md) — CLI и `config.ini`; пример `nodeos`.
* [Типовые схемы узлов](02_node-setups/index.md) — производящий и непроизводящий узлы.
* [Среда разработки](03_development-environment/index.md) — тестовая сеть для разработки.
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/chain_api_plugin/api-reference/index.md
+1
View File
@@ -0,0 +1 @@
[Справочник Chain API](https://docs.eosnetwork.com/coopos-plugins/latest/chain.api/)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/chain_api_plugin/index.md
+38
View File
@@ -0,0 +1,38 @@
## Описание
Плагин `chain_api_plugin` выставляет возможности [`chain_plugin`](../chain_plugin/index.md) через RPC API, которое обслуживает [`http_plugin`](../http_plugin/index.md).
## Использование
```console
# config.ini
plugin = eosio::chain_api_plugin
```
```sh
# command-line
nodeos ... --plugin eosio::chain_api_plugin
```
## Опции
Нет
## Зависимости
* [`chain_plugin`](../chain_plugin/index.md)
* [`http_plugin`](../http_plugin/index.md)
### Примеры загрузки зависимостей
```console
# config.ini
plugin = eosio::chain_plugin
[options]
plugin = eosio::http_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::chain_plugin [operations] [options] \
--plugin eosio::http_plugin [options]
```
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/chain_plugin/index.md
+244
View File
@@ -0,0 +1,244 @@
## Описание
Плагин `chain_plugin` — обязательный базовый модуль для обработки и агрегирования данных цепочки на узле COOPOS.
## Использование
```console
# config.ini
plugin = eosio::chain_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::chain_plugin [operations] [options]
```
## Операции (только CLI)
Задаются только в командной строке `nodeos`:
```console
Command Line Options for eosio::chain_plugin:
--genesis-json arg File to read Genesis State from
--genesis-timestamp arg override the initial timestamp in the
Genesis State file
--print-genesis-json extract genesis_state from blocks.log
as JSON, print to console, and exit
--extract-genesis-json arg extract genesis_state from blocks.log
as JSON, write into specified file, and
exit
--print-build-info print build environment information to
console as JSON and exit
--extract-build-info arg extract build environment information
as JSON, write into specified file, and
exit
--force-all-checks do not skip any validation checks while
replaying blocks (useful for replaying
blocks from untrusted source)
--disable-replay-opts disable optimizations that specifically
target replay
--replay-blockchain clear chain state database and replay
all blocks
--hard-replay-blockchain clear chain state database, recover as
many blocks as possible from the block
log, and then replay those blocks
--delete-all-blocks clear chain state database and block
log
--truncate-at-block arg (=0) stop hard replay / block log recovery
at this block number (if set to
non-zero number)
--terminate-at-block arg (=0) terminate after reaching this block
number (if set to a non-zero number)
--snapshot arg File to read Snapshot State from
```
## Опции
Доступны и в командной строке `nodeos`, и в `config.ini`:
```console
Config Options for eosio::chain_plugin:
--blocks-dir arg (="blocks") the location of the blocks directory
(absolute path or relative to
application data dir)
--state-dir arg (="state") the location of the state directory
(absolute path or relative to
application data dir)
--protocol-features-dir arg (="protocol_features")
the location of the protocol_features
directory (absolute path or relative to
application config dir)
--checkpoint arg Pairs of [BLOCK_NUM,BLOCK_ID] that
should be enforced as checkpoints.
--wasm-runtime runtime (=eos-vm-jit) Override default WASM runtime (
"eos-vm-jit", "eos-vm")
"eos-vm-jit" : A WebAssembly runtime
that compiles WebAssembly code to
native x86 code prior to execution.
"eos-vm" : A WebAssembly interpreter.
--profile-account arg The name of an account whose code will
be profiled
--abi-serializer-max-time-ms arg (=15)
Override default maximum ABI
serialization time allowed in ms
--chain-state-db-size-mb arg (=1024) Maximum size (in MiB) of the chain
state database
--chain-state-db-guard-size-mb arg (=128)
Safely shut down node when free space
remaining in the chain state database
drops below this size (in MiB).
--signature-cpu-billable-pct arg (=50)
Percentage of actual signature recovery
cpu to bill. Whole number percentages,
e.g. 50 for 50%
--chain-threads arg (=2) Number of worker threads in controller
thread pool
--contracts-console print contract's output to console
--deep-mind print deeper information about chain
operations
--actor-whitelist arg Account added to actor whitelist (may
specify multiple times)
--actor-blacklist arg Account added to actor blacklist (may
specify multiple times)
--contract-whitelist arg Contract account added to contract
whitelist (may specify multiple times)
--contract-blacklist arg Contract account added to contract
blacklist (may specify multiple times)
--action-blacklist arg Action (in the form code::action) added
to action blacklist (may specify
multiple times)
--key-blacklist arg Public key added to blacklist of keys
that should not be included in
authorities (may specify multiple
times)
--sender-bypass-whiteblacklist arg Deferred transactions sent by accounts
in this list do not have any of the
subjective whitelist/blacklist checks
applied to them (may specify multiple
times)
--read-mode arg (=head) Database read mode ("head",
"irreversible", "speculative").
In "head" mode: database contains state
changes up to the head block;
transactions received by the node are
relayed if valid.
In "irreversible" mode: database
contains state changes up to the last
irreversible block; transactions
received via the P2P network are not
relayed and transactions cannot be
pushed via the chain API.
In "speculative" mode: database
contains state changes by transactions
in the blockchain up to the head block
as well as some transactions not yet
included in the blockchain;
transactions received by the node are
relayed if valid.
--api-accept-transactions arg (=1) Allow API transactions to be evaluated
and relayed if valid.
--validation-mode arg (=full) Chain validation mode ("full" or
"light").
In "full" mode all incoming blocks will
be fully validated.
In "light" mode all incoming blocks
headers will be fully validated;
transactions in those validated blocks
will be trusted
--disable-ram-billing-notify-checks Disable the check which subjectively
fails a transaction if a contract bills
more RAM to another account within the
context of a notification handler (i.e.
when the receiver is not the code of
the action).
--maximum-variable-signature-length arg (=16384)
Subjectively limit the maximum length
of variable components in a variable
legnth signature to this size in bytes
--trusted-producer arg Indicate a producer whose blocks
headers signed by it will be fully
validated, but transactions in those
validated blocks will be trusted.
--database-map-mode arg (=mapped) Database map mode ("mapped",
"mapped_private", "heap", or "locked").
In "mapped" mode database is memory
mapped as a file.
In "mapped_private" mode database is
memory mapped as a file using a private
mapping (no disk writeback until
program exit).
In "heap" mode database is preloaded in
to swappable memory and will use huge
pages if available.
In "locked" mode database is preloaded,
locked in to memory, and will use huge
pages if available.
--eos-vm-oc-cache-size-mb arg (=1024) Maximum size (in MiB) of the EOS VM OC
code cache
--eos-vm-oc-compile-threads arg (=1) Number of threads to use for EOS VM OC
tier-up
--eos-vm-oc-enable arg (=auto) Enable EOS VM OC tier-up runtime
('auto', 'all', 'none').
'auto' - EOS VM OC tier-up is enabled
for eosio.* accounts, read-only trxs,
and applying blocks.
'all' - EOS VM OC tier-up is enabled
for all contract execution.
'none' - EOS VM OC tier-up is
completely disabled.
--enable-account-queries arg (=0) enable queries to find accounts by
various metadata.
--transaction-retry-max-storage-size-gb arg
Maximum size (in GiB) allowed to be
allocated for the Transaction Retry
feature. Setting above 0 enables this
feature.
--transaction-retry-interval-sec arg (=20)
How often, in seconds, to resend an
incoming transaction to network if not
seen in a block.
Needs to be at least twice as large as
p2p-dedup-cache-expire-time-sec.
--transaction-retry-max-expiration-sec arg (=120)
Maximum allowed transaction expiration
for retry transactions, will retry
transactions up to this value.
Should be larger than
transaction-retry-interval-sec.
--transaction-finality-status-max-storage-size-gb arg
Maximum size (in GiB) allowed to be
allocated for the Transaction Finality
Status feature. Setting above 0 enables
this feature.
--transaction-finality-status-success-duration-sec arg (=180)
Duration (in seconds) a successful
transaction's Finality Status will
remain available from being first
identified.
--transaction-finality-status-failure-duration-sec arg (=180)
Duration (in seconds) a failed
transaction's Finality Status will
remain available from being first
identified.
--integrity-hash-on-start Log the state integrity hash on startup
--integrity-hash-on-stop Log the state integrity hash on
shutdown
--block-log-retain-blocks arg If set to greater than 0, periodically
prune the block log to store only
configured number of most recent
blocks.
If set to 0, no blocks are be written
to the block log; block log file is
removed after startup.
```
## Зависимости
Нет
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/db_size_api_plugin/api-reference/index.md
+1
View File
@@ -0,0 +1 @@
[Справочник DB Size API](https://docs.eosnetwork.com/coopos-plugins/latest/db_size.api/)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/db_size_api_plugin/index.md
+40
View File
@@ -0,0 +1,40 @@
## Описание
Плагин `db_size_api_plugin` возвращает аналитику по блокчейну:
* free_bytes
* used_bytes
* size
* indices
<!--
## Использование
```console
# недоступно
```
-->
## Опции
Нет
## Зависимости
* [`chain_plugin`](../chain_plugin/index.md)
* [`http_plugin`](../http_plugin/index.md)
### Примеры загрузки зависимостей
```console
# config.ini
plugin = eosio::chain_plugin
[options]
plugin = eosio::http_plugin
[options]
```
```sh
# командная строка
nodeos ... --plugin eosio::chain_plugin [operations] [options] \
--plugin eosio::http_plugin [options]
```
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/http_plugin/index.md
+72
View File
@@ -0,0 +1,72 @@
## Описание
Плагин `http_plugin` поддерживается и `nodeos`, и `keosd`. Нужен для любой функциональности RPC API у экземпляра `nodeos` или `keosd`.
## Использование
```console
# config.ini
plugin = eosio::http_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::http_plugin [options]
(or)
keosd ... --plugin eosio::http_plugin [options]
```
## Опции
Задаются в командной строке и в `config.ini`:
```console
Config Options for eosio::http_plugin:
--unix-socket-path arg The filename (relative to data-dir) to
create a unix socket for HTTP RPC; set
blank to disable.
--http-server-address arg (=127.0.0.1:8888)
The local IP and port to listen for
incoming http connections; set blank to
disable.
--access-control-allow-origin arg Specify the Access-Control-Allow-Origin
to be returned on each request
--access-control-allow-headers arg Specify the Access-Control-Allow-Header
s to be returned on each request
--access-control-max-age arg Specify the Access-Control-Max-Age to
be returned on each request.
--access-control-allow-credentials Specify if Access-Control-Allow-Credent
ials: true should be returned on each
request.
--max-body-size arg (=2097152) The maximum body size in bytes allowed
for incoming RPC requests
--http-max-bytes-in-flight-mb arg (=500)
Maximum size in megabytes http_plugin
should use for processing http
requests. -1 for unlimited. 429 error
response when exceeded.
--http-max-in-flight-requests arg (=-1)
Maximum number of requests http_plugin
should use for processing http
requests. 429 error response when
exceeded.
--http-max-response-time-ms arg (=30) Maximum time for processing a request,
-1 for unlimited
--verbose-http-errors Append the error log to HTTP responses
--http-validate-host arg (=1) If set to false, then any incoming
"Host" header is considered valid
--http-alias arg Additionaly acceptable values for the
"Host" header of incoming HTTP
requests, can be specified multiple
times. Includes http/s_server_address
by default.
--http-threads arg (=2) Number of worker threads in http thread
pool
--http-keep-alive arg (=1) If set to false, do not keep HTTP
connections alive, even if client
requests.
```
## Зависимости
Нет
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/index.md
+24
View File
@@ -0,0 +1,24 @@
---
content_title: Плагины nodeos
---
## Обзор
Плагины расширяют базовую функциональность `nodeos`. Обязательные включают `chain_plugin`, `net_plugin` и `producer_plugin` — это отражает модульность `nodeos`. Остальные опциональны: удобные функции, но не обязательные для работы узла.
Описание конкретных плагинов — в списке:
* [`chain_api_plugin`](chain_api_plugin/index.md)
* [`chain_plugin`](chain_plugin/index.md)
* [`db_size_api_plugin`](db_size_api_plugin/index.md)
* [`http_plugin`](http_plugin/index.md)
* [`net_api_plugin`](net_api_plugin/index.md)
* [`net_plugin`](net_plugin/index.md)
* [`producer_plugin`](producer_plugin/index.md)
* [`state_history_plugin`](state_history_plugin/index.md)
* [`test_control_api_plugin`](test_control_api_plugin/index.md)
* [`test_control_plugin`](test_control_plugin/index.md)
* [`trace_api_plugin`](trace_api_plugin/index.md)
!!! note "Модульность nodeos"
Плагины добавляют возможности по шагам. В отличие от динамически подключаемых модулей, плагины `nodeos` собираются на этапе компиляции.
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/net_api_plugin/api-reference/index.md
+1
View File
@@ -0,0 +1 @@
[Справочник Net API](https://docs.eosnetwork.com/coopos-plugins/latest/net.api/)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/net_api_plugin/index.md
+49
View File
@@ -0,0 +1,49 @@
## Описание
Плагин `net_api_plugin` выставляет функции `net_plugin` через RPC API, которое ведёт `http_plugin`. Операторы узла могут управлять P2P-соединениями активного узла.
У `net_api_plugin` четыре конечные точки RPC API:
* connect
* disconnect
* connections
* status
См. [документацию Net API](https://docs.eosnetwork.com/coopos-plugins/latest/net.api/).
!!! warning "Осторожно"
Плагин открывает управление P2P-соединениями. Не рекомендуется включать его на публично доступном узле — возможна эксплуатация.
## Использование
```console
# config.ini
plugin = eosio::net_api_plugin
```
```sh
# command-line
nodeos ... --plugin eosio::net_api_plugin
```
## Опции
Нет
## Зависимости
* [`net_plugin`](../net_plugin/index.md)
* [`http_plugin`](../http_plugin/index.md)
### Примеры загрузки зависимостей
```console
# config.ini
plugin = eosio::net_plugin
[options]
plugin = eosio::http_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::net_plugin [options] \
--plugin eosio::http_plugin [options]
```
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/net_plugin/index.md
+107
View File
@@ -0,0 +1,107 @@
## Описание
Плагин `net_plugin` реализует аутентифицированный P2P-протокол для устойчивой синхронизации узлов.
## Использование
```console
# config.ini
plugin = eosio::net_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::net_plugin [options]
```
## Опции
Задаются в командной строке `nodeos` и в `config.ini`:
```console
Config Options for eosio::net_plugin:
--p2p-listen-endpoint arg (=0.0.0.0:9876)
The actual host:port used to listen for
incoming p2p connections.
--p2p-server-address arg An externally accessible host:port for
identifying this node. Defaults to
p2p-listen-endpoint.
--p2p-peer-address arg The public endpoint of a peer node to
connect to. Use multiple
p2p-peer-address options as needed to
compose a network.
Syntax: host:port[:<trx>|<blk>]
The optional 'trx' and 'blk'
indicates to node that only
transactions 'trx' or blocks 'blk'
should be sent. Examples:
p2p.example.org:9876
p2p.trx.example.org:9876:trx
p2p.blk.example.org:9876:blk
--p2p-max-nodes-per-host arg (=1) Maximum number of client nodes from any
single IP address
--p2p-accept-transactions arg (=1) Allow transactions received over p2p
network to be evaluated and relayed if
valid.
--agent-name arg (=EOS Test Agent) The name supplied to identify this node
amongst the peers.
--allowed-connection arg (=any) Can be 'any' or 'producers' or
'specified' or 'none'. If 'specified',
peer-key must be specified at least
once. If only 'producers', peer-key is
not required. 'producers' and
'specified' may be combined.
--peer-key arg Optional public key of peer allowed to
connect. May be used multiple times.
--peer-private-key arg Tuple of [PublicKey, WIF private key]
(may specify multiple times)
--max-clients arg (=25) Maximum number of clients from which
connections are accepted, use 0 for no
limit
--connection-cleanup-period arg (=30) number of seconds to wait before
cleaning up dead connections
--max-cleanup-time-msec arg (=10) max connection cleanup time per cleanup
call in milliseconds
--p2p-dedup-cache-expire-time-sec arg (=10)
Maximum time to track transaction for
duplicate optimization
--net-threads arg (=2) Number of worker threads in net_plugin
thread pool
--sync-fetch-span arg (=100) number of blocks to retrieve in a chunk
from any individual peer during
synchronization
--use-socket-read-watermark arg (=0) Enable experimental socket read
watermark optimization
--peer-log-format arg (=["${_name}" - ${_cid} ${_ip}:${_port}] )
The string used to format peers when
logging messages about them. Variables
are escaped with ${<variable name>}.
Available Variables:
_name self-reported name
_cid assigned connection id
_id self-reported ID (64 hex
characters)
_sid first 8 characters of
_peer.id
_ip remote IP address of peer
_port remote port number of peer
_lip local IP address connected to
peer
_lport local port number connected
to peer
--p2p-keepalive-interval-ms arg (=10000)
peer heartbeat keepalive message
interval in milliseconds
```
## Зависимости
Нет
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/producer_api_plugin/api-reference/index.md
+1
View File
@@ -0,0 +1 @@
[Справочник Producer API](https://docs.eosnetwork.com/coopos-plugins/latest/producer.api/)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/producer_api_plugin/index.md
+42
View File
@@ -0,0 +1,42 @@
## Описание
Плагин `producer_api_plugin` выставляет ряд конечных точек [`producer_plugin`](../producer_plugin/index.md) через RPC API под управлением [`http_plugin`](../http_plugin/index.md).
## Использование
```console
# config.ini
plugin = eosio::producer_api_plugin
```
```sh
# параметры запуска nodeos
nodeos ... --plugin eosio::producer_api_plugin
```
## Опции
Нет
## Зависимости
* [`producer_plugin`](../producer_plugin/index.md)
* [`chain_plugin`](../chain_plugin/index.md)
* [`http_plugin`](../http_plugin/index.md)
### Примеры загрузки зависимостей
```console
# config.ini
plugin = eosio::producer_plugin
[options]
plugin = eosio::chain_plugin
[options]
plugin = eosio::http_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::producer_plugin [options] \
--plugin eosio::chain_plugin [operations] [options] \
--plugin eosio::http_plugin [options]
```
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/producer_plugin/10_block-producing-explained.md
+85
View File
@@ -0,0 +1,85 @@
---
content_title: Как устроен выпуск блоков
---
Для наглядности введём обозначения:
* `r` = `producer_repetitions = 12` (жёстко задано)
* `m` = `max_block_cpu_usage` (консенсус в цепочке)
* `u` = `max_block_net_usage` (консенсус в цепочке)
* `t` = `block-time`
* `e` = `produce-block-offset-ms` (конфигурация nodeos)
* `w` = `block-time-interval = 500ms` (жёстко задано)
* `a` = `produce-block-early-amount = w - (w - (e / r)) = e / r ms` (насколько раньше выпускается каждый блок раунда)
* `l` = `produce block time = t - a`
* `p` = `окно выпуска блока = w - a` (доступное время стеновых часов на один блок)
* `c` = `billed_cpu_in_block = minimum(m, w - a)`
* `n` = `задержка сети TCP/IP`
* `h` = `время проверки заголовка блока, мс`
Валидация на пирах при схожем железе/версии/конфиге занимает ≤ `m`
**Пример: два BP и топология сети на схеме**
```
+------+ +------+ +------+ +------+
-->| BP-A |---->| BP-A |------>| BP-B |---->| BP-B |
+------+ | Peer | | Peer | +------+
+------+ +------+
```
`BP-A` отправляет блок в момент `l`, а `BP-B` должен получить блок к моменту `t`, иначе блок отбрасывается.
Если `BP-A` выпускает 12 блоков в моменты `b(lock) at t(ime) 1`, `bt 1.5`, `bt 2`, …, `bt 6.5`, то `BP-B` должен получить `bt 6.5` к моменту `6.5`, чтобы осталось `0.5` на выпуск `bt 7`.
Время `bt 7` минус `0.5` совпадает со временем `bt 6.5`, то есть `t` — время последнего блока `BP-A`, с которого `BP-B` должен начать свой первый блок.
Блок выпускается и отправляется, когда достигнут один из пределов: `m`, `u` или `p`.
Начиная с COOPOS 4.0, блоки распространяются после проверки заголовка. Вместо того чтобы пирам `BP-A` и `BP-B` тратить время порядка `m` на полную валидацию и пересылку, проверяется заголовок за миллисекунды и блок пересылается дальше.
Начиная с COOPOS 5.0, блоки в раунде стартуют сразу после завершения предыдущего. До 5.0 блоки всегда начинались с шагом `w`, и узел мог «спать» между блоками. В 5.0 паузы сдвинуты к концу раунда выпуска.
## Пример 1: блок приходит на 110 мс раньше
* Нулевая сетевая задержка между всеми узлами.
* Блоки не упираются в `m`, время выпуска каждого — `w - a`.
* Время завершения блока и подписи — ноль.
* У `BP-A`: e = 120, n = 0 мс, h = 5 мс, a = 10 мс
* `BP-A` шлёт b1 в `t1-10 мс` ⇒ `BP-A-Peer` обрабатывает `h=5 мс`, шлёт в `t-5 мс` ⇒ `BP-B-Peer` обрабатывает `h=5 мс`, шлёт в `t-0 мс` ⇒ приходит в `BP-B` в `t`.
* `BP-A` начинает b2 в `t1-10 мс`, шлёт b2 в `t2-20 мс` ⇒ … приходит в `BP-B` в `t2-10 мс`.
* `BP-A` начинает b3 в `t2-20 мс`, …
* `BP-A` начинает b12 в `t11-110 мс`, шлёт b12 в `t12-120 мс` ⇒ … приходит в `BP-B` в `t12-110 мс`
## Пример 2: блок приходит на 80 мс раньше
* Нулевая задержка между `BP-A` и `BP-A Peer` и между `BP-B Peer` и `BP-B`.
* 150 мс между `BP-A Peer` и `BP-B Peer`.
* Блоки не упираются в `m`, время выпуска — `w - a`.
* Время подписи — ноль.
* У `BP-A`: e = 240, n = 0/150 мс, h = 5 мс, a = 20 мс
* `BP-A` шлёт b1 в `t1-20 мс` ⇒ … приходит в `BP-B` в `t+140 мс`.
* `BP-A` начинает b2 в `t1-20 мс`, шлёт b2 в `t2-40 мс` ⇒ … приходит в `BP-B` в `t2+120 мс`.
* …
* b12 приходит в `BP-B` в `t12-80 мс`
## Пример 3: блок опоздал на 16 мс и отброшен
* Нулевая задержка между `BP-A` и `BP-A Peer` и между `BP-B Peer` и `BP-B`.
* 200 мс между `BP-A Peer` и `BP-B Peer`.
* Блоки не упираются в `m`, время выпуска — `w - a`.
* Время подписи — ноль.
* У `BP-A`: e = 204, n = 0/200 мс, h = 10 мс, a = 17 мс
* Цепочка задержек даёт приход b1 в `BP-B` в `t+203 мс`.
* …
* b12 приходит в `BP-B` в `t12+16 мс` — слишком поздно, блок отбрасывается.
## Пример 4: полные блоки выпускаются раньше
* Нулевая задержка между `BP-A` и `BP-A Peer` и между `BP-B Peer` и `BP-B`.
* 200 мс между `BP-A Peer` и `BP-B Peer`.
* Все блоки полные: в очереди достаточно неприменённых транзакций.
* Блок с транзакциями на 200 мс CPU по времени исполнения собирается за 225 мс (с учётом накладных расходов на выпуск блока).
* У `BP-A`: e = 120, m = 200 мс, n = 0/200 мс, h = 10 мс, a = 10 мс
* `BP-A` шлёт b1 в `t1-275 мс` ⇒ `BP-A-Peer` обрабатывает `h=10 мс`, шлёт в `t-265 мс` =(200 мс)=> `BP-B-Peer` обрабатывает `h=10 мс`, шлёт в `t-55 мс` ⇒ приходит в `BP-B` в `t-55 мс`.
* `BP-A` начинает b2 в `t1-275 мс`, шлёт b2 в `t2-550 мс (t1-50 мс)` ⇒ `BP-A-Peer` обрабатывает `h=10 мс`, шлёт в `t2-540 мс` =(200 мс)=> `BP-B-Peer` обрабатывает `h=10 мс`, шлёт в `t2-330 мс` ⇒ приходит в `BP-B` в `t2-330 мс`.
* `BP-A` начинает b3 в `t2-550 мс`, …
* `BP-A` начинает b12 в `t11-3025 мс`, шлёт b12 в `t12-3300 мс` ⇒ `BP-A-Peer` обрабатывает `h=10 мс`, шлёт в `t12-3290 мс` =(200 мс)=> `BP-B-Peer` обрабатывает `h=10 мс`, шлёт в `t12-3080 мс` ⇒ приходит в `BP-B` в `t12-3080 мс`
На ретрансляторе с `wasm-runtime=eos-vm-jit` и `eos-vm-oc-enable` время валидации сокращается.
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/producer_plugin/index.md
+134
View File
@@ -0,0 +1,134 @@
## Описание
Плагин `producer_plugin` подключает функции, необходимые узлу для выпуска блоков.
!!! note
Для выпуска блоков нужна дополнительная настройка: [Настройка производящего узла](../../02_usage/02_node-setups/00_producing-node.md).
## Использование
```console
# config.ini
plugin = eosio::producer_plugin [options]
```
```sh
# параметры запуска nodeos
nodeos ... --plugin eosio::producer_plugin [options]
```
## Опции
Задаются в командной строке `nodeos` и в `config.ini`:
```console
Config Options for eosio::producer_plugin:
-e [ --enable-stale-production ] Enable block production, even if the
chain is stale.
-x [ --pause-on-startup ] Start this node in a state where
production is paused
--max-transaction-time arg (=499) Setting this value (in milliseconds)
will restrict the allowed transaction
execution time to a value potentially
lower than the on-chain consensus
max_transaction_cpu_usage value.
--max-irreversible-block-age arg (=-1)
Limits the maximum age (in seconds) of
the DPOS Irreversible Block for a chain
this node will produce blocks on (use
negative value to indicate unlimited)
-p [ --producer-name ] arg ID of producer controlled by this node
(e.g. inita; may specify multiple
times)
--signature-provider arg (=EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEY:5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3)
Key=Value pairs in the form
<public-key>=<provider-spec>
Where:
<public-key> is a string form of
a valid EOS public
key
<provider-spec> is a string in the
form <provider-type>
:<data>
<provider-type> is KEY, KEOSD, or SE
KEY:<data> is a string form of
a valid EOS
private key which
maps to the provided
public key
KEOSD:<data> is the URL where
keosd is available
and the approptiate
wallet(s) are
unlocked
--greylist-account arg account that can not access to extended
CPU/NET virtual resources
--greylist-limit arg (=1000) Limit (between 1 and 1000) on the
multiple that CPU/NET virtual resources
can extend during low usage (only
enforced subjectively; use 1000 to not
enforce any limit)
--produce-block-offset-ms arg (=450) The minimum time to reserve at the end
of a production round for blocks to
propagate to the next block producer.
--max-block-cpu-usage-threshold-us arg (=5000)
Threshold of CPU block production to
consider block full; when within
threshold of max-block-cpu-usage block
can be produced immediately
--max-block-net-usage-threshold-bytes arg (=1024)
Threshold of NET block production to
consider block full; when within
threshold of max-block-net-usage block
can be produced immediately
--subjective-cpu-leeway-us arg (=31000)
Time in microseconds allowed for a
transaction that starts with
insufficient CPU quota to complete and
cover its CPU usage.
--subjective-account-max-failures arg (=3)
Sets the maximum amount of failures
that are allowed for a given account
per block.
--subjective-account-decay-time-minutes arg (=1440)
Sets the time to return full subjective
cpu for accounts
--incoming-transaction-queue-size-mb arg (=1024)
Maximum size (in MiB) of the incoming
transaction queue. Exceeding this value
will subjectively drop transaction with
resource exhaustion.
--disable-subjective-account-billing arg
Account which is excluded from
subjective CPU billing
--disable-subjective-p2p-billing arg (=1)
Disable subjective CPU billing for P2P
transactions
--disable-subjective-api-billing arg (=1)
Disable subjective CPU billing for API
transactions
--snapshots-dir arg (="snapshots") the location of the snapshots directory
(absolute path or relative to
application data dir)
```
## Dependencies
* [`chain_plugin`](../chain_plugin/index.md)
### Load Dependency Examples
```console
# config.ini
plugin = eosio::chain_plugin [operations] [options]
```
```sh
# command-line
nodeos ... --plugin eosio::chain_plugin [operations] [options]
```
Подробнее о выпуске блоков — в [пояснении по производству блоков](10_block-producing-explained.md).
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/resource_monitor_plugin/index.md
+52
View File
@@ -0,0 +1,52 @@
## Обзор
Плагин `resource_monitor_plugin` следит за заполнением дискового пространства на машине, где работает `nodeos`. Каждые `resource-monitor-interval-seconds` секунд измеряется использование файловых систем, к которым относятся `data-dir`, `state-dir`, `blocks-log-dir`, `snapshots-dir`, `state-history-dir` и `trace-dir`. Если на любом из отслеживаемых томов занято на `5%` меньше порога `resource-monitor-space-threshold`, выводится предупреждение с путём и процентом занятости. Если порог превышен и не задан `resource-monitor-not-shutdown-on-threshold-exceeded`, `nodeos` корректно завершается; если флаг задан, `nodeos` периодически печатает предупреждения, пока занятость не опустится ниже порога.
`resource_monitor_plugin` всегда загружен.
## Использование
```console
# config.ini
plugin = eosio::resource_monitor_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::resource_monitor_plugin [options]
```
## Параметры конфигурации
Задаются в командной строке `nodeos` и в `config.ini`:
```console
Config Options for eosio::resource_monitor_plugin:
--resource-monitor-interval-seconds arg (=2)
Time in seconds between two consecutive
checks of resource usage. Should be
between 1 and 300
--resource-monitor-space-threshold arg (=90)
Threshold in terms of percentage of
used space vs total space. If used
space is above (threshold - 5%), a
warning is generated. Unless
resource-monitor-not-shutdown-on-thresh
old-exceeded is enabled, a graceful
shutdown is initiated if used space is
above the threshold. The value should
be between 6 and 99
--resource-monitor-not-shutdown-on-threshold-exceeded
Used to indicate nodeos will not
shutdown when threshold is exceeded.
--resource-monitor-warning-interval arg (=30)
Number of resource monitor intervals
between two consecutive warnings when
the threshold is hit. Should be between
1 and 450
```
## Зависимости плагина
* Нет
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/state_history_plugin/10_how-to-fast-start-without-old-history.md
+40
View File
@@ -0,0 +1,40 @@
---
content_title: Быстрый старт без прежней истории
---
Эта схема подходит, если нужно **зафиксировать текущее состояние цепочки** и дальше вести **State History** только «вперёд», без полной локальной старой истории.
## Перед началом
* [Установлен COOPOS](../../../00_install/index.md).
* Знакомство с [использованием nodeos](../../02_usage/index.md).
* Знакомство с [state_history_plugin](../../03_plugins/state_history_plugin/index.md).
## Шаги
1. Подготовьте:
* переносимый снимок (`data/snapshots/snapshot-xxxxxxx.bin`)
* по желанию: `blocks.log`, включающий блок, на котором снят снимок
2. Убедитесь, что нет каталога `data/state`
3. Запустите `nodeos` с `--snapshot` и опциями из описания [`state_history_plugin`](index.md).
4. В логе найдите `Placing initial state in block n` — `n` это номер стартового блока.
5. Если используете filler БД, запустите его с `--fpg-create` (PostgreSQL), `--fill-skip-to n` и `--fill-trim`. Подставьте `n` из шага 4.
6. Не останавливайте `nodeos`, пока он не получит хотя бы один блок из сети — иначе перезапуск может быть невозможен.
## Замечания
Нет блоков из сети — подключите `net_api_plugin` и переподключите пиры: `cleos net disconnect` / `cleos net connect`.
!!! warning "Осторожно с `net_api_plugin`"
Закройте файрволом доступ к `http-server-address` или задайте `localhost:8888`, чтобы отключить удалённый доступ.
!!! note
После этого при перезапуске filler используйте `--fill-trim`. `--fpg-create` и `--fill-skip-to` — только при первом запуске.
!!! note
На крупных цепочках первая дельта может быть слишком большой для процессов JavaScript; 64-битные C++ процессы справляются. В filler’ах `fill-pg` и `fill-lmdb` большая запись дробится на меньшие при заполнении БД.
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/state_history_plugin/20_how-to-replay-or-resync-with-full-history.md
+17
View File
@@ -0,0 +1,17 @@
---
content_title: Реплей или ресинхронизация с полной историей
---
Полная история состояния на **nodeos** COOPOS: реплей или догонка с [`state_history_plugin`](index.md) от `blocks.log` или `--genesis-json`, чтобы с нуля записывалась вся цепочка в state history.
## Перед началом
* [COOPOS](../../../00_install/index.md), [nodeos](../../02_usage/index.md), [state_history_plugin](../../03_plugins/state_history_plugin/index.md).
## Шаги
1. Получите `blocks.log` и положите в `data/blocks`, либо возьмите файл генезиса и укажите `--genesis-json`
2. Убедитесь, что нет `data/state`, либо используйте `--replay-blockchain`
3. Запустите `nodeos` с опциями из [`state_history_plugin`](index.md)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/state_history_plugin/30_how-to-create-snapshot-with-full-history.md
+37
View File
@@ -0,0 +1,37 @@
---
content_title: Создание снимка с полной историей состояния
---
На узле **nodeos** COOPOS, где уже крутится полная state history с генезиса, снимается переносимый snapshot и копируются согласованные файлы `data/state-history` (и при необходимости `blocks.log`) для переноса или бэкапа.
## Перед началом
* [COOPOS](../../../00_install/index.md), [nodeos](../../02_usage/index.md), [state_history_plugin](../../03_plugins/state_history_plugin/index.md).
## Шаги
1. Включите `producer_api_plugin` на узле с полной state history.
!!! warning "Осторожно с `producer_api_plugin`"
Закройте файрволом доступ к `http-server-address` или укажите `localhost:8888`.
2. Создайте переносимый снимок:
```sh
curl http://127.0.0.1:8888/v1/producer/create_snapshot | json_pp
```
3. Дождитесь нескольких блоков после завершения снимка: в файлах state history должно быть минимум на один блок больше, чем в переносимом снимке, а в `blocks.log` — блок после того, как он стал необратимым.
!!! note "Примечание"
Если блок из снимка вытеснен форком, снимок недействителен — повторите процедуру.
4. Остановите `nodeos`.
5. Сохраните копии:
* нового переносимого снимка (`data/snapshots/snapshot-xxxxxxx.bin`)
* содержимого `data/state-history`:
* `chain_state_history.log`
* `trace_history.log`
* `chain_state_history.index` — по желанию; без него восстановление дольше
* `trace_history.index` — по желанию; без него восстановление дольше
* по желанию: `data/blocks` без `data/blocks/reversible`
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/state_history_plugin/40_how-to-restore-snapshot-with-full-history.md
+29
View File
@@ -0,0 +1,29 @@
---
content_title: Восстановление снимка с полной историей состояния
---
**nodeos** COOPOS поднимается из переносимого снимка вместе с каталогом state history, чтобы снова синхронизироваться с сетью и продолжить отдачу полной истории через [`state_history_plugin`](index.md).
## Перед началом
* [COOPOS](../../../00_install/index.md), [nodeos](../../02_usage/index.md), [state_history_plugin](../../03_plugins/state_history_plugin/index.md).
## Шаги
1. Подготовьте:
* переносимый снимок (`data/snapshots/snapshot-xxxxxxx.bin`)
* содержимое `data/state-history`
* по желанию: `blocks.log`, покрывающий блок снимка; без `data/blocks/reversible`
2. Убедитесь, что нет `data/state`
3. Запустите `nodeos` с `--snapshot` и опциями [`state_history_plugin`](index.md).
4. Не останавливайте `nodeos`, пока не получите хотя бы один блок из сети.
## Замечания
Блоки не идут — `net_api_plugin` и `cleos net disconnect` / `cleos net connect`.
!!! warning "Осторожно с `net_api_plugin`"
Закройте файрволом доступ к `http-server-address` или укажите `localhost:8888`.
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/state_history_plugin/index.md
+59
View File
@@ -0,0 +1,59 @@
## Описание
Плагин `state_history_plugin` сохраняет исторические данные о состоянии блокчейна. Получает данные от других узлов и кэширует их в файлах. Слушает сокет для подключения приложений и отдаёт данные согласно опциям, заданным при запуске `nodeos`.
## Использование
```console
# config.ini
plugin = eosio::state_history_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::state_history_plugin [operations] [options]
```
## Операции (только CLI)
Только командная строка `nodeos`:
```console
Command Line Options for eosio::state_history_plugin:
--delete-state-history clear state history files
```
## Опции
Командная строка `nodeos` и `config.ini`:
```console
Config Options for eosio::state_history_plugin:
--state-history-dir arg (="state-history")
the location of the state-history
directory (absolute path or relative to
application data dir)
--trace-history enable trace history
--chain-state-history enable chain state history
--state-history-endpoint arg (=127.0.0.1:8080)
the endpoint upon which to listen for
incoming connections. Caution: only
expose this port to your internal
network.
--state-history-unix-socket-path arg the path (relative to data-dir) to
create a unix socket upon which to
listen for incoming connections.
--trace-history-debug-mode enable debug mode for trace history
--state-history-log-retain-blocks arg if set, periodically prune the state
history files to store only configured
number of most recent blocks
```
## Практические руководства
* [Быстрый старт без старой истории на существующих цепочках](10_how-to-fast-start-without-old-history.md)
* [Реплей или ресинхронизация с полной историей](20_how-to-replay-or-resync-with-full-history.md)
* [Переносимый снимок с полной state history](30_how-to-create-snapshot-with-full-history.md)
* [Восстановление переносимого снимка с полной state history](40_how-to-restore-snapshot-with-full-history.md)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/test_control_api_plugin/api-reference/index.md
+1
View File
@@ -0,0 +1 @@
<!-- Заглушка: будет заменена экземпляром Redoc -->
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/test_control_api_plugin/index.md
+46
View File
@@ -0,0 +1,46 @@
## Описание
Плагин `test_control_api_plugin` отправляет управляющее сообщение в [test_control_plugin](../test_control_plugin/index.md), чтобы завершить экземпляр `nodeos` на заданном блоке. Для тестирования.
## Использование
```console
# config.ini
plugin = eosio::test_control_api_plugin
```
```sh
# command-line
nodeos ... --plugin eosio::test_control_api_plugin
```
## Опции
Нет
## Пример использования
```sh
curl %s/v1/test_control/kill_node_on_producer -d '{ \"producer\":\"%s\", \"where_in_sequence\":%d, \"based_on_lib\":\"%s\" }' -X POST -H \"Content-Type: application/json\"" %
```
## Зависимости
* [`test_control_plugin`](../test_control_plugin/index.md)
* [`chain_plugin`](../chain_plugin/index.md)
* [`http_plugin`](../http_plugin/index.md)
### Примеры загрузки зависимостей
```console
# config.ini
plugin = eosio::chain_plugin
[options]
plugin = eosio::http_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::chain_plugin [operations] [options] \
--plugin eosio::http_plugin [options]
```
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/test_control_plugin/index.md
+37
View File
@@ -0,0 +1,37 @@
## Описание
Плагин `test_control_plugin` инициирует корректное завершение при достижении заданного блока в последовательности блоков конкретного продюсера. Можно завершаться по **head block** или по **последнему необратимому блоку**.
Предназначен для тестов, чтобы точно зафиксировать момент остановки экземпляра `nodeos`.
## Использование
```console
# config.ini
plugin = eosio::test_control_plugin
```
```sh
# command-line
nodeos ... --plugin eosio::test_control_plugin
```
## Опции
Нет
## Зависимости
* [`chain_plugin`](../chain_plugin/index.md)
### Примеры загрузки зависимостей
```console
# config.ini
plugin = eosio::chain_plugin
[options]
```
```sh
# command-line
nodeos ... --plugin eosio::chain_plugin [operations] [options]
```
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/trace_api_plugin/api-reference/index.md
+1
View File
@@ -0,0 +1 @@
[Справочник Trace API](https://docs.eosnetwork.com/coopos-plugins/latest/trace.api/)
docs/documentation/blockchain/coopos/01_nodeos/03_plugins/trace_api_plugin/clog-format.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

docs/documentation/blockchain/coopos/01_nodeos/03_plugins/trace_api_plugin/index.md
+197
View File
@@ -0,0 +1,197 @@
## Обзор
Плагин `trace_api_plugin` даёт долговременное API «для потребителей» данных: завершённые (retired) действия и связанные метаданные по заданному блоку. Сериализованные трассировки блоков пишутся на диск и затем отдаются по HTTP RPC. Формальное описание интерфейса — в [справочнике Trace API](api-reference/index.md).
## Назначение
При интеграции обозревателей блоков, бирж и других приложений с блокчейном COOPOS часто нужна полная лента действий, обработанных цепочкой, включая порождённые смарт-контрактами и отложенные транзакции. Эту задачу закрывает `trace_api_plugin`:
* полная лента завершённых действий и метаданных
* долговременное API для выборки блоков
* управляемые затраты ресурсов на узлах COOPOS
Важная цель — упростить обслуживание ресурсов узла (ФС, диск, память). Это отличается от `history_plugin` с гибкой фильтрацией и запросами и от `state_history_plugin` с бинарным потоковым доступом к структурным данным цепочки, действиям и дельтам состояния.
## Использование
```console
# config.ini
plugin = eosio::trace_api_plugin
[options]
```
```sh
# командная строка
nodeos ... --plugin eosio::trace_api_plugin [options]
```
## Параметры конфигурации
Задаются в командной строке `nodeos` и в `config.ini`:
```console
Config Options for eosio::trace_api_plugin:
--trace-dir arg (="traces") the location of the trace directory
(absolute path or relative to
application data dir)
--trace-slice-stride arg (=10000) the number of blocks each "slice" of
trace data will contain on the
filesystem
--trace-minimum-irreversible-history-blocks arg (=-1)
Number of blocks to ensure are kept
past LIB for retrieval before "slice"
files can be automatically removed.
A value of -1 indicates that automatic
removal of "slice" files will be turned
off.
--trace-minimum-uncompressed-irreversible-history-blocks arg (=-1)
Number of blocks to ensure are
uncompressed past LIB. Compressed
"slice" files are still accessible but
may carry a performance loss on
retrieval
A value of -1 indicates that automatic
compression of "slice" files will be
turned off.
--trace-rpc-abi arg ABIs used when decoding trace RPC
responses.
There must be at least one ABI
specified OR the flag trace-no-abis
must be used.
ABIs are specified as "Key=Value" pairs
in the form <account-name>=<abi-def>
Where <abi-def> can be:
an absolute path to a file
containing a valid JSON-encoded ABI
a relative path from `data-dir` to a
file containing a valid JSON-encoded
ABI
--trace-no-abis Use to indicate that the RPC responses
will not use ABIs.
Failure to specify this option when
there are no trace-rpc-abi
configuations will result in an Error.
This option is mutually exclusive with
trace-rpc-api
```
## Зависимости
* [`chain_plugin`](../chain_plugin/index.md)
* [`http_plugin`](../http_plugin/index.md)
### Примеры загрузки зависимостей
Если плагины не указаны в CLI или `config.ini`, подключаются со значениями по умолчанию:
```console
# config.ini
plugin = eosio::chain_plugin
[options]
plugin = eosio::http_plugin
[options]
```
```sh
# командная строка
nodeos ... --plugin eosio::chain_plugin [options] \
--plugin eosio::http_plugin [options]
```
## Пример конфигурации
Пример запуска `nodeos` с `trace_api_plugin` для трассировки эталонных контрактов COOPOS:
```sh
nodeos --data-dir data_dir --config-dir config_dir --trace-dir traces_dir
--plugin eosio::trace_api_plugin
--trace-rpc-abi=eosio=abis/eosio.abi
--trace-rpc-abi=eosio.token=abis/eosio.token.abi
--trace-rpc-abi=eosio.msig=abis/eosio.msig.abi
--trace-rpc-abi=eosio.wrap=abis/eosio.wrap.abi
```
## Определения
Кратко о *слайсах* (slices), содержимом *trace log* и формате *clog*. Это помогает эффективно настраивать опции `trace_api_plugin`.
### Слайсы
Для `trace_api_plugin` *slice* — это все релевантные данные трассировки между начальной высотой блока (включительно) и конечной (не включая). Например, слайс 0–10 000 — блоки с номерами ≥ 0 и &lt; 10 000. В каталоге трассировок лежит набор слайсов. Каждый слайс состоит из журнала *trace data* и журнала метаданных *trace index*:
* `trace_<S>-<E>.log`
* `trace_index_<S>-<E>.log`
`<S>` и `<E>` — начальный и конечный номер блока слайса, дополненные ведущими нулями до ширины stride. Если старт — 5, конец — 15, stride — 10, то `<S>` = `0000000005`, `<E>` = `0000000015`.
#### trace_&lt;S&gt;-&lt;E&gt;.log
Журнал данных трассировки только дописывается; в нём бинарные сериализованные данные блока. Содержимое включает трассировки транзакций и действий для ответов RPC с учётом ABI по действиям. Поддерживаются типы блоков:
* `block_trace_v0`
* `block_trace_v1`
В начале — заголовок с версией формата. `block_trace_v0`: ID блока, номер, ID предыдущего, время производства, подписавший продюсер, данные трассировки. `block_trace_v1` добавляет корни Меркла для списков транзакций и действий и счётчик расписания продюсеров с генезиса.
В журнал могут попадать блоки, вытесненные форком — это нормально. Следующая запись имеет номер на 1 больше предыдущей или тот же/меньше из‑за форка. Каждой записи трассировки соответствует запись в индексном файле слайса. Блоки с форков можно уменьшить, запуская **nodeos** в `read-mode=irreversible`.
#### trace_index&#95;&lt;S&gt;-&lt;E&gt;.log
Индексный (метаданные) журнал только дописывается; в нём последовательность бинарно сериализованных типов. Сейчас поддерживаются:
* `block_entry_v0`
* `lib_entry_v0`
В начале — заголовок с версией. `block_entry_v0`: ID и номер блока и смещение к записи в журнале данных; по нему находят смещения `block_trace_v0` и `block_trace_v1`. `lib_entry_v0`: последний известный LIB. Модуль чтения использует LIB, чтобы сообщать пользователю статус необратимости.
### Формат clog
Сжатые журналы трассировок имеют расширение `.clog` (см. [сжатие журналов](#compression-of-log-files)). Это обобщённый сжатый файл с индексом точек распаковки в конце. Схема:
![](clog-format.png "clog format")
Данные сжимаются raw zlib с полными flush *seek points* через равные интервалы. Распаковщик может начать с любой *seek point* без чтения предыдущих данных; проход через seek point внутри потока тоже допустим.
!!! note "Экономия места под трассировки"
Сжатие может сократить рост каталога трассировок примерно в 20 раз. Например, при 512 seek points на тестовых данных публичной сети EOS рост каталога с полными данными падает с ~50 ГиБ/сут до ~2.5 ГиБ/сут. Из‑за избыточности содержимого сжатие сопоставимо с `gzip -9`. Распакованные данные сразу доступны через [Trace RPC API](api-reference/index.md) без деградации сервиса.
#### Роль seek points
При сжатии индекс точек запоминает соответствие смещений в несжатом и сжатом виде, чтобы по несжатому смещению найти ближайшую предшествующую seek point. Это сильно ускоряет позиционирование в конце длинного потока.
## Автообслуживание
Цель `trace_api_plugin` — уменьшить ручное обслуживание ФС: автоматически удалять старые журналы трассировок и сжимать их.
### Удаление журналов
Для автоматического удаления старых файлов, созданных `trace_api_plugin`:
```sh
--trace-minimum-irreversible-history-blocks N (=-1)
```
Если `N` ≥ 0, на диске остаются только `N` блоков до текущего LIB; файлы соответствующих более старых диапазонов помечаются на удаление.
### Сжатие журналов {#compression-of-log-files}
Оптимизация места — отдельная опция:
```sh
--trace-minimum-uncompressed-irreversible-history-blocks N (=-1)
```
При `N` ≥ 0 фоновый поток сжимает необратимые участки журналов; последние `N` необратимых блоков после LIB остаются несжатыми.
!!! note "Утилита Trace API"
Журналы можно сжимать вручную утилитой [trace_api_util](../../../10_utilities/trace_api_util.md).
Если опций `trace-minimum-irreversible-history-blocks` и `trace-minimum-uncompressed-irreversible-history-blocks` недостаточно, может понадобиться периодическое ручное обслуживание или внешний планировщик.
## Ручное обслуживание
Опция `trace-dir` задаёт каталог файлов трассировки `trace_api_plugin`. После прохождения LIB за пределы слайса файлы стабильны и их можно удалять для освобождения места. Развёрнутая система COOPOS переносит внепроцессное удаление любых файлов в этом каталоге — независимо от того, обращается ли к ним запущенный **nodeos**. Данные, которые формально должны быть доступны, но удалены вручную, дают HTTP 404 на соответствующих endpoint’ах.
!!! note "Для операторов узлов"
Срок хранения истории на узле можно полностью контролировать через `trace-api-plugin`, опции `trace-minimum-irreversible-history-blocks` и `trace-minimum-uncompressed-irreversible-history-blocks` и внешние менеджеры дискового пространства.
docs/documentation/blockchain/coopos/01_nodeos/04_replays/how-to-generate-a-blocks.log.md
+8
View File
@@ -0,0 +1,8 @@
---
content_title: Как сформировать файл blocks.log
---
В COOPOS **nodeos** пишет необратимые блоки в `blocks.log` под каталогом данных (по умолчанию `data/blocks`) — локальная неизменяемая копия цепочки на этом узле. Другой каталог задаётся `-d` / `--data-dir`.
!!! note "Другие файлы `blocks.log`"
`blocks.log` можно также получить у сторонних поставщиков.
docs/documentation/blockchain/coopos/01_nodeos/04_replays/how-to-generate-a-snapshot.md
+17
View File
@@ -0,0 +1,17 @@
---
content_title: Как создать снимок
---
У запущенного **nodeos** COOPOS снимок создаётся вызовом `create_snapshot` у `producer_api_plugin`. Файл попадает в `data/snapshots` относительно `--data-dir`; имя обычно вида `snapshot-<head_block_id_in_hex>.bin`.
!!! note "Каталог снимков"
Каталог данных задаёт `-d` / `--data-dir`; внутри него — `data/snapshots`.
Если `nodeos` слушает локально, запрос на создание снимка:
```sh
curl -X POST http://127.0.0.1:8888/v1/producer/create_snapshot
```
!!! note "Журнал блоков отдельно"
Готовый `blocks.log` иногда берут у сторонних поставщиков — для реплея или догонки без полной синхронизации.
docs/documentation/blockchain/coopos/01_nodeos/04_replays/how-to-replay-from-a-blocks.log.md
+23
View File
@@ -0,0 +1,23 @@
---
content_title: Как воспроизвести цепочку из blocks.log
---
Скопируйте нужный `blocks.log` в `data/blocks`, при необходимости сохраните старые файлы, удалите `blocks.index`, `forkdb.dat`, `shared_memory.bin` и `shared_memory.meta`.
Каталог | Файл | Действие
----------------------- | ------------------ | ------
data/blocks | blocks.index | удалить
data/blocks | blocks.log | заменить нужным `blocks.log`
data/blocks/reversible | forkdb.dat | удалить
data/blocks/reversible | shared_memory.bin | удалить
data/blocks/reversible | shared_memory.meta | удалить
Каталог блоков задаётся в `config.ini` как `blocks-dir = "blocks"` или опцией `--blocks-dir`.
```sh
nodeos --replay-blockchain \
--plugin eosio::producer_plugin \
--plugin eosio::chain_api_plugin \
--plugin eosio::http_plugin \
>> nodeos.log 2>&1 &
```
docs/documentation/blockchain/coopos/01_nodeos/04_replays/how-to-replay-from-a-snapshot.md
+30
View File
@@ -0,0 +1,30 @@
---
content_title: Как воспроизвести цепочку из снимка
---
Получив валидный файл снимка, скопируйте его в `data/snapshots`, при необходимости сделайте резервную копию и удалите существующее содержимое каталога данных.
Расположение | Имя | Действие
----------------- | -------------------------- | ------------
data/snapshots | `<head block id in hex>.bin` | положить сюда снимок для реплея
data/ | * | удалить
В `config.ini` можно задать `snapshots-dir = "snapshots"` или использовать `--snapshots-dir` в командной строке; `--snapshot` указывает имя файла снимка для восстановления.
```sh
nodeos --snapshot yoursnapshot.name \
--plugin eosio::producer_plugin \
--plugin eosio::chain_api_plugin \
--plugin eosio::http_plugin \
>> nodeos.log 2>&1 &
```
При старте со снимка рекомендуется убрать старые данные; если при этом есть `blocks.log`, он *должен* содержать блоки как минимум до блока снимка и *может* содержать последующие блоки — они применятся при запуске. Если `blocks.log` есть, но не покрывает блок снимка или последующие блоки неконсистентны, при реплее со снимка будет исключение. Также применяются доступные обратимые блоки.
blocks.log | снимок | результат
------------------------ | --------------------------- | ------
нет | для необратимого блока 2000 | ок
блоки 1–1999 | для необратимого блока 2000 | исключение
блоки 1–2001 | для необратимого блока 2000 | ок — состояние из снимка и применение блока 2001
При подъёме узла из снимка нельзя передавать `nodeos` аргументы `--genesis-json` или `--genesis-timestamp` — генезис берётся из снимка. Если `blocks.log` уже есть, его генезис сверяется с данными снимка; при несовпадении реплей завершится ошибкой (проверка, что журнал и снимок относятся к одной цепочке).
docs/documentation/blockchain/coopos/01_nodeos/04_replays/index.md
+51
View File
@@ -0,0 +1,51 @@
---
content_title: Реплеи nodeos
---
У `nodeos` есть варианты воспроизведения блоков цепочки. Это полезно, например, если узел скачал `blocks.log` (быстрее, чем полная синхронизация по P2P) и нужно догнать сеть, или если нужно состояние цепочки в конкретные моменты времени.
Воспроизведение возможно двумя способами:
- Из файла **`blocks.log`**:
В `blocks.log` хранятся все необратимые транзакции. Каждый `nodeos` дописывает необратимые блоки в `blocks.log` в каталоге `data/blocks` относительно данных `nodeos`. Реплей по `blocks.log` пересоздаёт локально всю историю без лишней нагрузки на сеть.
- Из **файла снимка (snapshot)**:
Снимок создаётся с работающего `nodeos` и содержит состояние цепочки на блоке, с которого он снят. Рекомендуется использовать снимки с необратимых блоков. Реплей со снимка быстро поднимает `nodeos` с корректным состоянием на заданном номере блока, но без полной истории транзакций до этого блока. Далее узел работает в обычном режиме.
## Практические инструкции
* [Как сформировать журнал блоков](how-to-generate-a-blocks.log.md)
* [Как создать снимок](how-to-generate-a-snapshot.md)
* [Как воспроизвести цепочку из журнала блоков](how-to-replay-from-a-blocks.log.md)
* [Как воспроизвести цепочку из снимка](../04_replays/how-to-replay-from-a-snapshot.md)
## Опции, связанные со снимками и реплеем
Команда `nodeos --help` выводит все опции. Касающиеся снимков и реплея:
- **`--force-all-checks`**
Если источник `blocks.log` не доверен, при первом реплее можно запустить `nodeos` с `--replay-blockchain --force-all-checks`, чтобы не пропускать проверки блоков.
- **`--disable-replay-opts`**
По умолчанию при реплее `nodeos` не строит стек дельт состояния (он нужен для отката состояния по обратимым блокам) — это ускоряет реплей. Данная опция отключает эту оптимизацию. Для `state_history_plugin` она обязательна.
- **`--replay-blockchain`**
Очистить состояние цепочки и воспроизвести все блоки из `blocks.log` в каталоге `data/blocks`.
- **`--hard-replay-blockchain`**
Сделать резервную копию текущего `blocks.log`, очистить состояние и воспроизвести блоки из журнала. Предполагается, что в резервной копии `blocks.log` могут быть повреждённые блоки: `nodeos` воспроизводит максимум возможного из резервной копи, а при первом повреждённом блоке досинхронизируется по P2P.
- **`--delete-all-blocks`**
Очистить локальное состояние цепочки и локальный `blocks.log`. Для последующей синхронизации по P2P нужен корректный `genesis.json`. Опция не рекомендуется.
- **`--truncate-at-block`**
Аргумент по умолчанию `=0`; если задан ненулевой, при реплее воспроизведение останавливается на указанном номере блока. Работает только вместе с `--hard-replay-blockchain`. Локальный процесс `nodeos` будет иметь состояние на этом блоке. Удобно для проверок в тестах; для узла, синхронизированного с сетью, не предназначено.
- **`--snapshot`**
Путь к файлу снимка для восстановления состояния без реплея `blocks.log`. Полной истории транзакций до снимка у экземпляра `nodeos` не будет.
- **`--snapshots-dir`**
Каталог файлов снимков (абсолютный путь или относительно каталога данных приложения).
- **`--blocks-dir`**
Каталог с `blocks.log` (абсолютный путь или относительно каталога данных приложения).
docs/documentation/blockchain/coopos/01_nodeos/05_rpc_apis/index.md
+11
View File
@@ -0,0 +1,11 @@
---
content_title: Удалённые вызовы (RPC API)
link_text: RPC API
---
* [Справочник Chain API](../03_plugins/chain_api_plugin/api-reference/index.md)
* [Справочник DB Size API](../03_plugins/db_size_api_plugin/api-reference/index.md)
* [Справочник Net API](../03_plugins/net_api_plugin/api-reference/index.md)
* [Справочник Producer API](../03_plugins/producer_api_plugin/api-reference/index.md)
* [Справочник Test Control API](../03_plugins/test_control_api_plugin/api-reference/index.md)
* [Справочник Trace API](../03_plugins/trace_api_plugin/api-reference/index.md)
docs/documentation/blockchain/coopos/01_nodeos/06_logging/00_setup-logging.json.md
+16
View File
@@ -0,0 +1,16 @@
---
content_title: Настройка logging.json
---
Файл `logging.json` обычно лежит в каталоге `--config-dir` рядом с `config.ini`. Явный путь задаётся опциями `-l` или `--logconf` при запуске `nodeos`.
```sh
nodeos --help
```
```console
...
Application Command Line Options:
...
--config-dir arg Directory containing configuration files such as config.ini
-l [ --logconf ] arg (=logging.json) Logging configuration file name/path for library users
```
docs/documentation/blockchain/coopos/01_nodeos/06_logging/01_logging-levels.md
+87
View File
@@ -0,0 +1,87 @@
---
content_title: Уровни логирования
---
Доступны шесть уровней:
- all
- debug
- info
- warn
- error
- off
Пример `logging.json`:
```
{
"includes": [],
"appenders": [{
"name": "consoleout",
"type": "console",
"args": {
"stream": "std_out",
"level_colors": [{
"level": "debug",
"color": "green"
},{
"level": "warn",
"color": "brown"
},{
"level": "error",
"color": "red"
}
]
},
"enabled": true
},{
"name": "net",
"type": "gelf",
"args": {
"endpoint": "10.10.10.10",
"host": "test"
},
"enabled": true
}
],
"loggers": [{
"name": "default",
"level": "info",
"enabled": true,
"additivity": false,
"appenders": [
"consoleout",
"net"
]
},{
"name": "net_plugin_impl",
"level": "debug",
"enabled": true,
"additivity": false,
"appenders": [
"net"
]
}
]
}
```
## Смысл уровней
* `error` — события, вероятно требующие вмешательства оператора.
- Уровень `error` стоит оставлять для неожиданных ситуаций или тех, где нужен человек.
- Также для явных ошибок ПО: невозможные значения перечислений, выход за границы массива, нулевые указатели и т.п., часто ведущие к исключению.
- *Замечание*: сейчас много сообщений с уровнем `error` логичнее отнести к `warn` — например, в `net_plugin_impl` для плохих сетевых соединений, которые обрабатываются штатно; такие случаи лучше перевести на `warn` или `info`.
* `warn` — неожиданное, но восстановимое.
- Обычно не требует немедленного вмешательства, но частые `warn` могут сигнализировать о действиях оператора.
- `warn` не стоит использовать просто как «информацию» — это сигнал обратить внимание, без обязательной тревоги.
* `info` (по умолчанию) — полезная оператору информация.
- Прогресс и полезные данные; стараются не засыпать логом: например, не логировать каждую транзакцию на `info`.
- Для прогресса логируют через интервалы, например каждые 1000 транзакций.
* `debug` — детали при включённом нетипичном логировании.
- Вопрос: полезно ли это оператору, смотрящему лог. Объём как у `info`: не раздувать.
- Включение `debug` должно прояснять поведение без лавины строк.
- `debug` не заменяет трассировку; для неё — `all` (см. ниже).
- Как и для `info`, не логировать каждую транзакцию на `debug`; для транзакций есть отдельные логгеры: `transaction`, `transaction_trace_failure`, `transaction_trace_success`, `transaction_failure_tracing`, `transaction_success_tracing`, `transient_trx_success_tracing`, `transient_trx_failure_tracing`.
* `all` (trace) — то, что при `debug` засыпало бы лог.
- Трассировочный уровень; поддержан частично.
- *Замечание*: в будущем другая библиотека логирования может дать лучшую трассировку; текущая среда не рассчитана на огромный объём trace-вывода.
docs/documentation/blockchain/coopos/01_nodeos/06_logging/index.md
+110
View File
@@ -0,0 +1,110 @@
---
content_title: Логирование nodeos
---
Логирование `nodeos` задаётся файлом `logging.json`. Опции CLI при запуске `nodeos` позволяют [настроить `logging.json`](00_setup-logging.json.md). В конфигурации задаются [аппендеры](#appenders), привязка к [логгерам](#loggers) и [уровни логирования](01_logging-levels.md).
## Аппендеры {#appenders}
Встроенная библиотека логирования COOPOS поддерживает два типа аппендеров:
- [Консоль](#console)
- [GELF](#gelf) (Graylog Extended Log Format)
### Консоль {#console}
Вывод сообщений на экран. Параметры:
- `name` — произвольное имя для ссылок из логгеров
- `type` — `"console"`
- `stream` — `"std_out"` или `"std_err"`
- `level_colors` — сопоставление уровня логирования цвету
- level — см. [уровни логирования](01_logging-levels.md)
- color — одно из: `"red"`, `"green"`, `"brown"`, `"blue"`, `"magenta"`, `"cyan"`, `"white"`, `"console_default"`
- `enabled` — включить/выключить аппендер
Пример:
```json
{
"name": "consoleout",
"type": "console",
"args": {
"stream": "std_out",
"level_colors": [{
"level": "debug",
"color": "green"
},{
"level": "warn",
"color": "brown"
},{
"level": "error",
"color": "red"
}
]
},
"enabled": true
}
```
### GELF {#gelf}
Отправка сообщений в Graylog — платформу сбора, индексации и анализа логов. Параметры:
- `name` — произвольное имя для ссылок из логгеров
- `type` — `"gelf"`
- `endpoint` — IP-адрес и порт
- `host` — имя хоста в Graylog, идентификатор источника
- `enabled` — включить/выключить аппендер
Пример:
```json
{
"name": "net",
"type": "gelf",
"args": {
"endpoint": "104.198.210.18:12202”,
"host": <YOURNAMEHERE IN QUOTES>
},
"enabled": true
}
```
## Логгеры {#loggers}
Поддерживаются такие логгеры:
- `default` — логгер по умолчанию, всегда включён
- `net_plugin_impl` — подробный лог сетевого плагина
- `http_plugin` — подробный лог HTTP-плагина
- `producer_plugin` — подробный лог плагина продюсера
- `transaction_tracing` — подробный лог вердиктов ретрансляторов в P2P
- `transaction_failure_tracing` — подробный лог неуспешных вердиктов в P2P
- `trace_api` — подробный лог плагина trace_api
Параметры:
- `name` — должно совпадать с одним из имён выше
- `level` — см. уровни ниже
- `enabled` — включить/выключить логгер
- `additivity` — `true` или `false`
- `appenders` — список имён аппендеров из конфигурации аппендеров
Пример:
```json
{
"name": "net_plugin_impl",
"level": "debug",
"enabled": true,
"additivity": false,
"appenders": [
"net"
]
}
```
!!! note
Если `logging.json` нет, у всех логгеров по умолчанию уровень `info`. В `logging.json` каждый логгер настраивается отдельно.
docs/documentation/blockchain/coopos/01_nodeos/07_concepts/05_storage-and-read-modes.md
+60
View File
@@ -0,0 +1,60 @@
---
content_title: Хранилище и режимы чтения
---
Платформа COOPOS хранит данные блокчейна в разных структурах на этапах жизненного цикла транзакции. Ниже — часть из них. Производящий узел — это экземпляр `nodeos` у того продюсера, который сейчас создаёт блоки (роль меняется примерно каждые 6 секунд: 12 блоков подряд, затем другой продюсер.)
## Состояние блокчейна и хранение
Каждый `nodeos` создаёт внутренние файлы для учёта состояния цепочки. Они лежат в каталоге установки `~/eosio/nodeos/data`; назначение:
* `blocks.log` — только дописываемый журнал необратимых блоков с финальными подтверждёнными транзакциями.
* `reversible_blocks` — memory-mapped файл с блоками, уже записанными в цепочку, но ещё не необратимыми; в них — валидные транзакции, ожидающие финализации по консенсусу. Head block — последний записанный блок, хранится в `reversible_blocks`.
* `chain state` / `chain database` — в memory-mapped файле кэшируется состояние цепочки по блокам: аккаунты, отложенные транзакции, данные multi_index смарт-контрактов. Кэшируются ID последних 65 536 блоков для TaPOS. ID транзакции и срок действия кэшируются до истечения транзакции.
* `pending block` — блок в памяти с транзакциями по мере обработки; он станет или может стать head block. Если этот `nodeos` — производящий узел, pending block рассылается другим экземплярам `nodeos`.
* Вне состояния цепочки данные блоков кэшируются в RAM до необратимости; кэшируется в том числе подписанный блок. Когда LIB догоняет блок, блок читается из журнала необратимых блоков.
## Интерфейсы COOPOS
COOPOS даёт [сервисы](../../) и [интерфейсы](https://docs.eosnetwork.com/cdt/latest/reference/Files/), чтобы контракты сохраняли состояние между действиями и транзакциями. Например, контракт `eosio.token` хранит балансы в базе состояния цепочки. Каждый `nodeos` держит БД в памяти, поэтому чтение/запись в контрактах просты.
### HTTP RPC API nodeos
Через HTTP [RPC API](../05_rpc_apis/index.md) сервис `nodeos` отдаёт запросы к базе состояния цепочки.
## Режимы чтения nodeos
`nodeos` можно запускать в разных режимах «чтения». Они влияют на обработку блоков и транзакций:
- `head`: учитываются только побочные эффекты подтверждённых транзакций; необработанные транзакции обрабатываются, но в состояние не включаются.
- `irreversible`: только подтверждённые транзакции до последнего необратимого блока включительно.
- `speculative`: побочные эффекты подтверждённых и неподтверждённых транзакций.
Транзакция считается подтверждённой, когда `nodeos` принял её, обработал и записал в блок цепочки — она в head block или раньше.
### Режим head
Клиенты (`cleos`, RPC API) видят состояние БД на текущий head block. Head ещё не необратим, возможны короткие форки — при переключении на лучшую ветку прочитанное состояние может устареть.
В этом режиме `nodeos` может выполнять транзакции с TaPoS, указывающим на любой валидный блок в лучшей по мнению узла ветке.
### Режим irreversible
`nodeos` по-прежнему отслеживает актуальные блоки в fork database, но отображаемое состояние отстаёт от «головы» форка (fork DB head) и соответствует последнему необратимому блоку.
Клиенты (`cleos`, RPC API) видят состояние БД по последнему необратимому блоку и **не** включают изменения от транзакций, известных узлу, но ещё не попавших в цепочку (в т.ч. неподтверждённых).
### Режим speculative (устарел)
Клиенты видят состояние head block плюс изменения от всех известных узлу транзакций, которые могут ещё не попасть в цепочку.
Низкая задержка, но хрупко: нет гарантии, что эти транзакции попадут в цепочку или в том же порядке, что подразумевает видимое состояние.
Минимальная задержка при максимальной непоследовательности.
В speculative режиме `nodeos` может выполнять транзакции с TaPoS на любой валидный блок лучшей ветки.
## Как задать режим чтения
Режим задаётся опцией `--read-mode` плагина `eosio::chain_plugin`.
docs/documentation/blockchain/coopos/01_nodeos/07_concepts/10_context-free-data/index.md
+16
View File
@@ -0,0 +1,16 @@
---
content_title: Контекстно-свободные данные (CFD)
link_text: Контекстно-свободные данные
---
## Обзор
Неизменяемость блокчейна защищает данные и их целостность, но усложняет удаление несущественной информации. В транзакциях COOPOS есть отдельная секция — *context-free data*. Как следует из названия, эти данные не привязаны к предыдущему контексту и зависимостям, поэтому их теоретически можно удалять безопаснее. Удаление не должно ломать целостность цепочки.
## Идея
Контекстно-свободные данные позволяют приложениям хранить в транзакции необязательную информацию. Примеры:
* Вторичные или кратковременные данные цепочки
* Краткосрочная некритичная информация к сообщению транзакции
* Комментарии пользователей к статье в блокчейне
В общем случае сюда относится всё, что не критично для работы и целостности цепочки. Также CFD можно использовать для соблюдения требований законодательства о персональных данных.
docs/documentation/blockchain/coopos/01_nodeos/07_concepts/index.md
+8
View File
@@ -0,0 +1,8 @@
---
content_title: Концепции nodeos
---
Раздел с пояснениями по `nodeos`, практиками и деталями реализации.
* [Хранилище и режимы чтения](05_storage-and-read-modes.md) — состояние блокчейна, хранение, режимы чтения `nodeos`.
* [Context-free data](10_context-free-data/index.md) — цели, плюсы и операции с контекстно-свободными данными.
docs/documentation/blockchain/coopos/01_nodeos/08_troubleshooting/index.md
+47
View File
@@ -0,0 +1,47 @@
---
content_title: Устранение неполадок nodeos
---
### «Database dirty flag set (likely due to unclean shutdown): replay required»
`nodeos` нужно останавливать корректно: отправьте `SIGTERM`, `SIGQUIT` или `SIGINT` и дождитесь завершения. Иначе возможна эта ошибка. Тогда остаётся реплей: запуск `nodeos` с `--replay-blockchain`.
### Ошибка «Memory does not match data» при перезапуске
При сообщении вроде `St9exception: content of memory does not match data expected by executable` попробуйте запустить `nodeos` с одной из опций (полный список — `nodeos --help`):
```
Command Line Options for eosio::chain_plugin:
--force-all-checks do not skip any checks that can be
skipped while replaying irreversible
blocks
--replay-blockchain clear chain state database and replay
all blocks
--hard-replay-blockchain clear chain state database, recover as
many blocks as possible from the block
log, and then replay those blocks
--delete-all-blocks clear chain state database and block
log
```
### Ошибка «Could not grow database file to requested size.»
Запустите `nodeos` с `--shared-memory-size-mb 1024`. Файл shared memory ~1 ГБ позволяет порядка полумиллиона транзакций.
### Какая версия COOPOS запущена / к какой версии подключаюсь?
При настройках по умолчанию `cleos get info` покажет поле `server_version`. Если `nodeos` не на дефолтном URL, укажите адрес:
```sh
cleos --url http://localhost:8888 get info
```
Только строка версии:
```sh
cleos --url http://localhost:8888 get info | grep server_version
```
### Ошибка 3070000: WASM Exception
При развёртывании `eosio.bios` или `eosio.system` для загрузки цепочки на базе COOPOS и ошибке вроде `Publishing contract... Error 3070000: WASM Exception Error Details: env.set_proposed_producers_ex unresolveable` нужно сначала активировать протокольную функцию `PREACTIVATE_FEATURE`.
docs/documentation/blockchain/coopos/01_nodeos/index.md
+29
View File
@@ -0,0 +1,29 @@
---
content_title: nodeos
---
!!! note "Сеть COOPOS"
**nodeos** — демон узла COOPOS. Ресурсы сети и системный контракт (в т. ч. для **cleos**): [справка](../system-resources.md).
## Введение
`nodeos` — основной сервисный демон на каждом узле COOPOS. Его можно настроить на обработку смарт-контрактов, проверку транзакций, выпуск блоков с валидными транзакциями и финализацию блоков для записи в цепочку.
## Установка
`nodeos` входит в [репозиторий COOPOS](https://github.com/coopenomics/coopos). Раздел установки: [Установка ПО COOPOS](../00_install/index.md).
## Навигация
Ниже — разделы по настройке и использованию `nodeos`.
* [Использование](02_usage/index.md) — конфигурация и запуск `nodeos`, типовые схемы узлов и среды разработки.
* [Плагины](03_plugins/index.md) — плагины, опции, обязательные и необязательные.
* [Реплеи](04_replays/index.md) — воспроизведение цепочки из снимка или файла `blocks.log`.
* [RPC API](05_rpc_apis/index.md) — справка по HTTP RPC для плагинов.
* [Логирование](06_logging/index.md) — `logging.json`, логгеры, аппендеры, уровни.
* [Концепции](07_concepts/index.md) — пояснения и детали реализации `nodeos`.
* [Устранение неполадок](08_troubleshooting/index.md) — типичные проблемы `nodeos`.
!!! note "Узел доступа"
Клиентскому приложению или смарт-контракту нужен локальный или удалённый узел COOPOS с запущенным `nodeos`.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-buy-ram.md
+23
View File
@@ -0,0 +1,23 @@
## Обзор
Здесь показано, как купить RAM на аккаунт через `cleos system buyram` — чтобы хватило квоты на развёртывание контракта, таблицы состояния и рост данных на цепи.
## Перед началом
* У вас есть аккаунт.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* На аккаунте достаточно токенов.
* Установлена поддерживаемая версия `cleos`.
* Разблокируйте кошелёк.
## Шаги
Купить RAM на сумму 0.1 SYS для аккаунта `alice`:
```sh
cleos system buyram alice alice "0.1 SYS" -p alice@active
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-config-a-multisig-account.md
+20
View File
@@ -0,0 +1,20 @@
## Обзор
На этой странице показан пример настройки разрешения `active` аккаунта так, чтобы для действий требовались подписи нескольких аккаунтов (порог и веса в `authority`). Это основа для мультиподписи при работе через `cleos`.
## Перед началом
* У вас есть аккаунт.
* Выделено достаточно ресурсов для выполнения транзакции.
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: [аккаунт и разрешения](../../../accounts.md) и [транзакции](../../../transactions.md).
## Шаги
```sh
cleos set account permission multisig active '{\"threshold\" : 1, \"accounts\" :[{\"permission\":{\"actor\":\"eosio\",\"permission\":\"active\"},\"weight\":1},{\"permission\":{\"actor\":\"customera\",\"permission\":\"active\"},\"weight\":1}]}' owner -p multisig@owner"
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-connect-a-specific-network.md
+23
View File
@@ -0,0 +1,23 @@
## Обзор
На этой странице показано, как направить `cleos` на конкретный хост `nodeos` или `keosd`, чтобы выполнить нужную команду против удалённого или нестандартного API. Для этого используются необязательные аргументы `--url` и `--wallet-url` с HTTP-адресом и портом сервиса.
!!! note "Адрес и порт по умолчанию"
Если необязательные аргументы не заданы (т.е. без `--url` или `--wallet-url`), `cleos` пытается подключиться к локальным `nodeos` или `keosd` на `127.0.0.1` и порту по умолчанию `8888`.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
## Шаги
### Подключение к nodeos
```sh
cleos -url http://nodeos-host:8888 COMMAND
```
### Подключение к keosd
```sh
cleos --wallet-url http://keosd-host:8888 COMMAND
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-create-a-wallet.md
+58
View File
@@ -0,0 +1,58 @@
## Обзор
Здесь описано, как создать кошелёк `keosd` через `cleos wallet create` и сохранить пароль в файл — чтобы затем импортировать ключи и подписывать транзакции из CLI.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Ознакомьтесь с командой [`cleos wallet create`](../03_command-reference/wallet/create.md) и её параметрами.
* Ознакомьтесь с остальными командами [`cleos wallet`](../03_command-reference/wallet/index.md).
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
`cleos` входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и `cleos`.
* Нужны базовые понятия: [аккаунт](../../../accounts.md), [аккаунты и разрешения](../../../accounts.md) и пара открытого/закрытого ключа в этой модели.
## Шаги
Выполните шаг ниже.
Создайте кошелёк по умолчанию или с именем и сохраните пароль кошелька в файл:
```sh
cleos wallet create [-n named_wallet] -f <file_to_save_pwd>
```
Здесь `file_to_save_pwd` — имя файла, в который записывается пароль кошелька, а `named_wallet` — необязательный параметр для имени кошелька.
Ниже приведены примеры.
* Создать кошелёк по умолчанию и сохранить пароль в файл `default_wallet.pwd`:
**Пример вывода**
```sh
cleos wallet create -f default_wallet.pwd
```
```console
Creating wallet: default
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
saving password to default_wallet.pwd
```
* Создать именованный кошелёк `my_wallet` и сохранить пароль в файл `my_wallet.pwd`:
**Пример вывода**
```sh
cleos wallet create -n my_wallet -f my_wallet.pwd
```
```console
Creating wallet: my_wallet
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
saving password to my_wallet.pwd
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-create-an-account.md
+53
View File
@@ -0,0 +1,53 @@
## Обзор
В этом руководстве описано, как создать новый аккаунт блокчейна COOPOS с помощью CLI `cleos`. Аккаунты нужны для развёртывания смарт-контрактов и других операций в блокчейне. Создайте один или несколько аккаунтов при настройке среды разработки.
В примере создаётся аккаунт **bob**, авторизованный системным аккаунтом по умолчанию **eosio**, через `cleos`.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Установлена поддерживаемая версия `cleos`.
* Изучите раздел [Аккаунты и разрешения](../../../accounts.md).
* Нужны базовые понятия: пара открытого и закрытого ключа в той же модели (см. [аккаунты](../../../accounts.md)).
* Создайте пары открытого/закрытого ключа для разрешений `owner` и `active` аккаунта.
!!! note "Состав COOPOS"
`cleos` входит в пакет COOPOS; при [установке из исходников](../../00_install/index.md) ставится вместе с `nodeos` и `keosd`.
## Справка по командам
См. справку по использованию `cleos` и опциям:
* команда [`cleos create account`](../03_command-reference/create/account.md) и её параметры
## Процедура
Ниже показано, как создать аккаунт **bob**, авторизованный системным аккаунтом **eosio**.
1. Выполните команду для создания аккаунта **bob**:
```sh
cleos create account eosio bob EOS87TQktA5RVse2EguhztfQVEh6XXxBmgkU8b4Y5YnGvtYAoLGNN
```
**Где**:
* `eosio` — системный аккаунт, авторизующий создание нового аккаунта
* `bob` — имя нового аккаунта в соответствии с [правилами имён и разрешений](../../../accounts.md)
* `EOS87TQ...AoLGNN` — открытый ключ владельца или уровень разрешения для нового аккаунта (**обязательно**)
!!! note "Кто может создать аккаунт"
Нужен уже существующий аккаунт-создатель с правом вызвать `newaccount`. В чистой тестовой сети для этого обычно используют системный аккаунт **eosio**. В продуктовой сети COOPOS создание новых аккаунтов идёт по правилам регистратора — см. [ресурсы и регистрация](../../../system-resources.md).
**Пример вывода**
```console
executed transaction: 4d65a274de9f809f9926b74c3c54aadc0947020bcfb6dd96043d1bcd9c46604c 200 bytes 166 us
# eosio <= eosio::newaccount {"creator":"eosio","name":"bob","owner":{"threshold":1,"keys":[{"key":"EOS87TQktA5RVse2EguhztfQVEh6X...
warning: transaction executed locally, but may not be confirmed by the network yet ]
```
### Итог
Следуя этим шагам, вы создаёте новый аккаунт COOPOS в своей среде.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-create-key-pairs.md
+70
View File
@@ -0,0 +1,70 @@
## Обзор
В этом руководстве описано, как создать пару ключей (открытый и закрытый) для подписи транзакций в блокчейне COOPOS.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: асимметричная криптография (пара открытого и закрытого ключа) в модели аккаунтов COOPOS; см. также [аккаунты и разрешения](../../../accounts.md).
!!! note "Состав COOPOS"
Утилита `cleos` входит в пакет COOPOS: при [установке из исходников](../../00_install/index.md) она собирается вместе с `nodeos` и `keosd`.
## Справка по командам
См. справку по использованию `cleos` и опциям:
* команда [`cleos create key`](../03_command-reference/create/key.md) и её параметры
## Процедура
Ниже показано, как создать пару открытого/закрытого ключа, вывести её в консоль и сохранить в файл:
1. Создайте пару и выведите её в консоль:
```sh
cleos create key --to-console
```
**Где**:
* `--to-console` — опция для вывода пары ключей в консоль
**Пример вывода**
```console
Private key: 5KPzrqNMJdr6AX6abKg*******************************cH
Public key: EOS4wSiQ2jbYGrqiiKCm8oWR88NYoqnmK4nNL1RCtSQeSFkGtqsNc
```
2. Создайте пару и сохраните её в файл:
```sh
cleos create key --file pw.txt
```
**Где**:
* `--file` — опция для сохранения пары ключей в файл
* `FILE_TO_SAVEKEY` — имя файла для сохранения пары ключей
**Пример вывода**
```console
saving keys to pw.txt
```
Чтобы посмотреть сохранённую пару в файле:
```sh
cat pw.txt
```
```console
Private key: 5K7************************************************
Public key: EOS71k3WdpLDeqeyqVRAAxwpz6TqXwDo9Brik5dQhdvvpeTKdNT59
```
## Итог
Следуя этим шагам, вы создаёте пары открытого/закрытого ключа, выводите их в консоль и сохраняете в файл.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-delegate-CPU-resource.md
+45
View File
@@ -0,0 +1,45 @@
## Обзор
Здесь показано, как делегировать пропускную способность CPU с одного аккаунта на другой через `cleos system delegatebw` — чтобы выделить CPU получателю (при необходимости в той же транзакции можно указать и NET).
## Перед началом
Убедитесь, что выполнены следующие требования:
* Ознакомьтесь с командой [`cleos system delegatebw`](../03_command-reference/system/system-delegatebw.md) и её параметрами.
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
`cleos` входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория [`reference-contracts`](https://github.com/Coopenomics/reference-contracts) для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md) в COOPOS.
## Шаги
Выполните шаг ниже.
Делегируйте пропускную способность CPU с исходного аккаунта на аккаунт-получатель:
```sh
cleos system delegatebw <from> <receiver> <stake_net_quantity> <stake_cpu_quantity>
```
Здесь `from` — аккаунт, с которого делегируется пропускная способность, `receiver` — аккаунт-получатель, а `stake_net_quantity` и/или `stake_cpu_quantity` — объём токенов в стейке для NET и/или CPU соответственно.
Ниже приведены примеры.
* Делегировать 0.01 SYS на пропускную способность CPU от `bob` к `alice`:
**Пример вывода**
```sh
cleos system delegatebw bob alice "0 SYS" "0.01 SYS"
```
```json
executed transaction: 5487afafd67bf459a20fcc2dbc5d0c2f0d1f10e33123eaaa07088046fd18e3ae 192 bytes 503 us
# eosio <= eosio::delegatebw {"from":"bob","receiver":"alice","stake_net_quantity":"0.0000 SYS","stake_cpu_quantity":"0.0100 SYS"...
# eosio.token <= eosio.token::transfer {"from":"bob","to":"eosio.stake","quantity":"0.0010 SYS","memo":"stake bandwidth"}
# bob <= eosio.token::transfer {"from":"bob","to":"eosio.stake","quantity":"0.0010 SYS","memo":"stake bandwidth"}
# eosio.stake <= eosio.token::transfer {"from":"bob","to":"eosio.stake","quantity":"0.0010 SYS","memo":"stake bandwidth"}
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-delegate-net-resource.md
+45
View File
@@ -0,0 +1,45 @@
## Обзор
Здесь показано, как делегировать пропускную способность сети (NET) с одного аккаунта на другой через `cleos system delegatebw` — чтобы выделить NET получателю, при необходимости задействовав и CPU в той же команде.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Ознакомьтесь с командой [`cleos system delegatebw`](../03_command-reference/system/system-delegatebw.md) и её параметрами.
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
`cleos` входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория [`reference-contracts`](https://github.com/Coopenomics/reference-contracts) для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md) в COOPOS.
## Шаги
Выполните шаг ниже.
Делегируйте пропускную способность сети (NET) с исходного аккаунта на аккаунт-получатель:
```sh
cleos system delegatebw <from> <receiver> <stake_net_quantity> <stake_cpu_quantity>
```
Здесь `from` — аккаунт, с которого делегируется пропускная способность, `receiver` — аккаунт-получатель, а `stake_net_quantity` и/или `stake_cpu_quantity` — объём токенов в стейке для NET и/или CPU соответственно.
Ниже приведены примеры.
* Делегировать 0.01 SYS на пропускную способность сети (NET) от `bob` к `alice`:
**Пример вывода**
```sh
cleos system delegatebw bob alice "0.01 SYS" "0 SYS"
```
```json
executed transaction: 5487afafd67bf459a20fcc2dbc5d0c2f0d1f10e33123eaaa07088046fd18e3ae 192 bytes 503 us
# eosio <= eosio::delegatebw {"from":"bob","receiver":"alice","stake_net_quantity":"0.0100 SYS","stake_cpu_quantity":"0.0000 SYS"...
# eosio.token <= eosio.token::transfer {"from":"bob","to":"eosio.stake","quantity":"0.0010 SYS","memo":"stake bandwidth"}
# bob <= eosio.token::transfer {"from":"bob","to":"eosio.stake","quantity":"0.0010 SYS","memo":"stake bandwidth"}
# eosio.stake <= eosio.token::transfer {"from":"bob","to":"eosio.stake","quantity":"0.0010 SYS","memo":"stake bandwidth"}
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-deploy-a-smart-contract.md
+22
View File
@@ -0,0 +1,22 @@
## Обзор
На этой странице описано, как развернуть WASM и ABI смарт-контракта на аккаунте в сети COOPOS командой `cleos set contract` — обычный шаг после сборки контракта в среде разработки.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Разблокируйте кошелёк, в котором есть закрытый ключ аккаунта контракта.
## Шаги
Выполните:
```sh
cleos set contract contract_account contract_folder [wasm-file] [abi-file]
```
Подставьте вместо `contract_folder` путь к каталогу с контрактом.
!!! note "Имя контракта по умолчанию"
По умолчанию `cleos` считает именем контракта последний сегмент пути в `contract_folder` и ожидает файлы `.wasm` и `.abi` с таким именем. Это можно переопределить необязательными параметрами `wasm-file` и `abi-file`.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-get-account-information.md
+56
View File
@@ -0,0 +1,56 @@
## Обзор
В этом руководстве описано, как запросить информацию об аккаунте COOPOS через `cleos get account` — квоты RAM, полосы NET/CPU и дерево разрешений. В примере запрашиваются данные аккаунта `eosio`.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
Утилита cleos входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и cleos.
* Полезно заранее прочитать раздел [Аккаунты и разрешения](../../../accounts.md) в документации по блокчейну.
## Справка по командам
См. справку по использованию cleos и опциям:
* команда [`cleos get account`](../03_command-reference/get/account.md) и её параметры
## Процедура
Ниже показано, как запросить информацию об аккаунте `eosio`:
1. Выполните команду:
```sh
cleos get account eosio
```
**Где**:
* `eosio` — имя системного аккаунта по умолчанию в блокчейне COOPOS.
**Пример вывода**
```console
created: 2018-06-01T12:00:00.000
privileged: true
permissions:
owner 1: 1 EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
active 1: 1 EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
memory:
quota: unlimited used: 3.004 KiB
net bandwidth:
used: unlimited
available: unlimited
limit: unlimited
cpu bandwidth:
used: unlimited
available: unlimited
limit: unlimited
```
!!! note "Поля аккаунта"
В зависимости от сети COOPOS набор полей аккаунта может отличаться — это определяется развёрнутым системным контрактом.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-get-block-information.md
+81
View File
@@ -0,0 +1,81 @@
## Обзор
Здесь показано, как запросить у API `nodeos` полные данные блока по номеру или по идентификатору — чтобы проверить время, подпись производителя, состав транзакций и связь с предыдущим блоком при отладке или мониторинге сети.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Ознакомьтесь с командой [`cleos get block`](../03_command-reference/get/block.md) и её параметрами.
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
`cleos` входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и `cleos`.
* Полезно знать, как [блоки формируются и распространяются по сети](../../../nodes.md), и общие идеи [протокола консенсуса](../../../protocols.md) в COOPOS.
## Шаги
Выполните шаг ниже.
Получите полную информацию о блоке:
```sh
cleos get block <block_number_or_id>
```
Здесь `block_number_or_id` — номер блока или идентификатор блока.
Ниже приведены примеры.
* Запросить в тестовой сети полную информацию о блоке с номером `48351112` или с ID `02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba`:
**Пример вывода**
```sh
cleos -u https://choiceofyourprovider get block 48351112
```
См. раздел [среда разработки и тестовые сети](../../01_nodeos/02_usage/03_development-environment/index.md)
```json
{
"timestamp": "2021-01-28T17:58:59.500",
"producer": "inith",
"confirmed": 0,
"previous": "02e1c78787ff4d4ce6124831b936bb4ef6015e470868a535f1c6e04f3afed8a1",
"transaction_mroot": "0000000000000000000000000000000000000000000000000000000000000000",
"action_mroot": "1bf9d17b5a951cbb6d0a8324e4039744db4137df498abd53046ea26fa74d73c9",
"schedule_version": 1,
"new_producers": null,
"producer_signature": "SIG_K1_JxFfxGA1wZx9LCVjbrBb5nxTuJai7RUSiwRXyY866fYvZZyRtdmQFn9KJCqVHFAiYEsJpDb6dhTmHNDwipJm4rDiyhEmGa",
"transactions": [],
"id": "02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba",
"block_num": 48351112,
"ref_block_prefix": 3493375603
}
```
* Запросить в тестовой сети полную информацию о блоке с ID `02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba`:
**Пример вывода**
```sh
cleos -u https://choiceofyourprovider get block 02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba
```
```json
{
"timestamp": "2021-01-28T17:58:59.500",
"producer": "inith",
"confirmed": 0,
"previous": "02e1c78787ff4d4ce6124831b936bb4ef6015e470868a535f1c6e04f3afed8a1",
"transaction_mroot": "0000000000000000000000000000000000000000000000000000000000000000",
"action_mroot": "1bf9d17b5a951cbb6d0a8324e4039744db4137df498abd53046ea26fa74d73c9",
"schedule_version": 1,
"new_producers": null,
"producer_signature": "SIG_K1_JxFfxGA1wZx9LCVjbrBb5nxTuJai7RUSiwRXyY866fYvZZyRtdmQFn9KJCqVHFAiYEsJpDb6dhTmHNDwipJm4rDiyhEmGa",
"transactions": [],
"id": "02e1c7888a92206573ae38d00e09366c7ba7bc54cd8b7996506f7d2a619c43ba",
"block_num": 48351112,
"ref_block_prefix": 3493375603
}
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-get-tables-information.md
+15
View File
@@ -0,0 +1,15 @@
## Обзор
Здесь показана команда `cleos get table` для чтения строк таблицы состояния смарт-контракта по аккаунту контракта, scope и имени таблицы — удобно для отладки и инспекции данных на цепи.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: [аккаунт контракта](../../../accounts.md), а также что такое таблица и scope в модели хранения состояния WASM-контракта (первичный ключ и область видимости строк).
## Шаги
```sh
cleos get table ACCOUNT SCOPE TABLE
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-get-transaction-information.md
+199
View File
@@ -0,0 +1,199 @@
## Обзор
В этом руководстве описано, как получить по ID полные данные транзакции в COOPOS — например, чтобы разобрать действия, подписи и след в блоке после отладки или инцидента.
В примере запрашиваются данные транзакции, связанной с созданием аккаунта **bob**.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
`cleos` входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и `cleos`.
* Полезно заранее знать, [как устроены транзакции](../../../transactions.md) в блокчейне COOPOS.
## Справка по командам
См. справку по использованию `cleos` и опциям:
* команда [`cleos get transaction`](../03_command-reference/get/transaction.md) и её параметры
## Процедура
Ниже показано, как получить информацию о транзакции, связанной с созданием аккаунта **bob**.
1. Запросите транзакцию по ID:
```sh
cleos get transaction 870a6b6e3882061ff0f64016e1eedfdd9439e2499bf978c3fb29fcedadada9b1
```
* Здесь `870a6b6e38...dada9b1` — идентификатор транзакции создания аккаунта **bob**.
**Пример вывода**
Команда `cleos` возвращает подробные данные транзакции:
```json
{
"id": "870a6b6e3882061ff0f64016e1eedfdd9439e2499bf978c3fb29fcedadada9b1",
"trx": {
"receipt": {
"status": "executed",
"cpu_usage_us": 3493,
"net_usage_words": 25,
"trx": [
1,{
"signatures": [
"SIG_K1_KYEvKx3nC81H6brKXHNjhrw32rNtTC2dP6nYFjZvj1N3k7KSU4CXBTJyiXd38ANu2ZPTUf66qUghUp5Jarkhiqdx3D8pwf"
],
"compression": "none",
"packed_context_free_data": "",
"packed_trx": "0c252e60fe001fe2acca00000000010000000000ea305500409e9a2264b89a010000000000ea305500000000a8ed3232660000000000ea30550000000000000e3d01000000010002dfcee032f2e84bfc8ecc5c10fffb870ec1c690c1f3fdae3d8b7d65690b6455560100000001000000010002dfcee032f2e84bfc8ecc5c10fffb870ec1c690c1f3fdae3d8b7d65690b6455560100000000"
}
]
},
"trx": {
"expiration": "2021-02-18T08:27:56",
"ref_block_num": 254,
"ref_block_prefix": 3400327711,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio",
"name": "newaccount",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": {
"creator": "eosio",
"name": "bob",
"owner": {
"threshold": 1,
"keys": [{
"key": "EOS6b4ENeXffuKGmsk3xCk3kbFM5M8dcANrUa9Mj9RzKLNhPKhzyj",
"weight": 1
}
],
"accounts": [],
"waits": []
},
"active": {
"threshold": 1,
"keys": [{
"key": "EOS6b4ENeXffuKGmsk3xCk3kbFM5M8dcANrUa9Mj9RzKLNhPKhzyj",
"weight": 1
}
],
"accounts": [],
"waits": []
}
},
"hex_data": "0000000000ea30550000000000000e3d01000000010002dfcee032f2e84bfc8ecc5c10fffb870ec1c690c1f3fdae3d8b7d65690b6455560100000001000000010002dfcee032f2e84bfc8ecc5c10fffb870ec1c690c1f3fdae3d8b7d65690b64555601000000"
}
],
"transaction_extensions": [],
"signatures": [
"SIG_K1_KYEvKx3nC81H6brKXHNjhrw32rNtTC2dP6nYFjZvj1N3k7KSU4CXBTJyiXd38ANu2ZPTUf66qUghUp5Jarkhiqdx3D8pwf"
],
"context_free_data": []
}
},
"block_time": "2021-02-18T08:27:27.000",
"block_num": 256,
"last_irreversible_block": 305,
"traces": [{
"action_ordinal": 1,
"creator_action_ordinal": 0,
"closest_unnotified_ancestor_action_ordinal": 0,
"receipt": {
"receiver": "eosio",
"act_digest": "2640ce4d4a789393dec3b7938cea2f78c5669498d0d22adeab9204c489c2cfd6",
"global_sequence": 256,
"recv_sequence": 256,
"auth_sequence": [[
"eosio",
256
]
],
"code_sequence": 0,
"abi_sequence": 0
},
"receiver": "eosio",
"act": {
"account": "eosio",
"name": "newaccount",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": {
"creator": "eosio",
"name": "bob",
"owner": {
"threshold": 1,
"keys": [{
"key": "EOS6b4ENeXffuKGmsk3xCk3kbFM5M8dcANrUa9Mj9RzKLNhPKhzyj",
"weight": 1
}
],
"accounts": [],
"waits": []
},
"active": {
"threshold": 1,
"keys": [{
"key": "EOS6b4ENeXffuKGmsk3xCk3kbFM5M8dcANrUa9Mj9RzKLNhPKhzyj",
"weight": 1
}
],
"accounts": [],
"waits": []
}
},
"hex_data": "0000000000ea30550000000000000e3d01000000010002dfcee032f2e84bfc8ecc5c10fffb870ec1c690c1f3fdae3d8b7d65690b6455560100000001000000010002dfcee032f2e84bfc8ecc5c10fffb870ec1c690c1f3fdae3d8b7d65690b64555601000000"
},
"context_free": false,
"elapsed": 1565,
"console": "",
"trx_id": "870a6b6e3882061ff0f64016e1eedfdd9439e2499bf978c3fb29fcedadada9b1",
"block_num": 256,
"block_time": "2021-02-18T08:27:27.000",
"producer_block_id": null,
"account_ram_deltas": [{
"account": "bob",
"delta": 2724
}
],
"except": null,
"error_code": null
}
]
}
```
!!! note
Для запроса информации о транзакции нужен экземпляр `nodeos` с включёнными [плагином history](../../01_nodeos/03_plugins/history_plugin/index.md) и [плагином history API](../../01_nodeos/03_plugins/history_api_plugin/index.md).
## Итог
Следуя этим шагам, вы получаете информацию о транзакции по её идентификатору.
## Устранение неполадок
Если в `nodeos` в файле **config.ini** не включены [плагин history](../../01_nodeos/03_plugins/history_plugin/index.md) и [плагин history API](../../01_nodeos/03_plugins/history_api_plugin/index.md), команда `cleos get transaction` с ID завершится ошибкой, например:
```sh
cleos get transaction 509eee3aa8988d533a336fec7a4c8b067ae3205cd97e2d27b3e9a2da61ef460c
```
```console
Error 3110003: Missing History API Plugin
Ensure that you have eosio::history_api_plugin added to your node's configuration!
Error Details:
History API plugin is not enabled
```
Чтобы устранить ошибку, включите [плагин history](../../01_nodeos/03_plugins/history_plugin/index.md) и [плагин history API](../../01_nodeos/03_plugins/history_api_plugin/index.md), затем выполните команду снова.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-import-a-key.md
+50
View File
@@ -0,0 +1,50 @@
## Обзор
В этом руководстве описано, как импортировать закрытый ключ в кошелёк `keosd` по умолчанию, чтобы `cleos` мог подписывать транзакции от имени соответствующего аккаунта в блокчейне COOPOS.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Создайте кошелёк по умолчанию командой `cleos wallet create`. Инструкции — в разделе [Как создать кошелёк](../02_how-to-guides/how-to-create-a-wallet.md).
* Откройте и разблокируйте созданный кошелёк.
* Ознакомьтесь с командой [`cleos wallet import`](../03_command-reference/wallet/import.md).
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: пара [открытого и закрытого ключа](../../../accounts.md) в модели аккаунтов COOPOS.
!!! note "Состав COOPOS"
`cleos` входит в пакет COOPOS; при [установке из исходников](../../00_install/index.md) ставится вместе с `nodeos` и `keosd`.
## Справка по командам
См. справку по использованию `cleos` и опциям:
* [cleos wallet import](../03_command-reference/wallet/import.md) — команда и параметры
## Процедура
Ниже показано, как импортировать закрытый ключ в существующий кошелёк `keosd` по умолчанию:
1. Выполните команду импорта закрытого ключа в кошелёк по умолчанию. Будет запрошен закрытый ключ:
```sh
cleos wallet import
```
```console
private key:
```
2. Введите закрытый ключ и нажмите Enter.
```sh
***
```
**Пример вывода**
Команда подтверждает успешный импорт, выводя соответствующий открытый ключ:
```console
imported private key for: EOS8FBXJUfbANf3xeDWPoJxnip3Ych9HjzLBr1VaXRQFdkVAxwLE7
```
## Итог
Следуя этим шагам, вы импортируете закрытый ключ в кошелёк по умолчанию.
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-link-permission.md
+17
View File
@@ -0,0 +1,17 @@
## Обзор
Здесь показано, как привязать отдельное разрешение к конкретному действию (action) контракта через `cleos set action permission` — чтобы для вызова, например, `transfer` использовался не `active`, а специальное минимально необходимое разрешение.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: [аккаунт и уровни разрешений](../../../accounts.md), а также действие (action) смарт-контракта в модели COOPOS/EOSIO (см. [транзакции](../../../transactions.md)).
## Шаги
Свяжите уровень разрешения `permlvl` с действием `transfer` контракта `hodlcontract`:
```sh
cleos set action permission alice hodlcontract transfer permlvl
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-list-all-key-pairs.md
+113
View File
@@ -0,0 +1,113 @@
## Обзор
В этом руководстве описано, как вывести список всех открытых ключей и пар открытый/закрытый в кошельке `keosd` по умолчанию — чтобы проверить, какие ключи доступны для подписи, и при необходимости скопировать открытый ключ. Эти ключи используются для авторизации транзакций в блокчейне COOPOS.
В примере показаны все открытые ключи и пары, хранящиеся в существующем кошельке по умолчанию.
## Перед началом
Убедитесь, что выполнены следующие требования:
* Создайте кошелёк по умолчанию командой `cleos wallet create`. Инструкции — в разделе [Как создать кошелёк](../02_how-to-guides/how-to-create-a-wallet.md).
* [Создайте пару ключей](../03_command-reference/wallet/create_key.md) в кошельке по умолчанию.
* Ознакомьтесь с командами [`cleos wallet`](../03_command-reference/wallet/index.md).
* Установлена поддерживаемая версия `cleos`.
!!! note "Примечание"
`cleos` входит в состав ПО COOPOS. При [установке COOPOS](../../00_install/index.md) устанавливается и `cleos`.
* Нужны базовые понятия: пара [открытого и закрытого ключа](../../../accounts.md) в модели аккаунтов COOPOS.
## Справка по командам
См. справку по использованию `cleos` и опциям:
* команда [`cleos wallet keys`](../03_command-reference/wallet/keys.md) и её параметры
* команда [`cleos wallet private_keys`](../03_command-reference/wallet/private_keys.md) и её параметры
## Процедура
Ниже показано, как вывести все открытые ключи и пары открытый/закрытый в кошельке `keosd` по умолчанию:
1. Откройте кошелёк по умолчанию:
```sh
cleos wallet open
```
```console
Opened: default
```
2. Разблокируйте кошелёк по умолчанию. Будет запрошен пароль:
```sh
cleos wallet unlock
```
```console
password:
```
3. Введите пароль, заданный при создании кошелька по умолчанию:
```sh
***
```
Если пароль верный, кошелёк разблокируется:
```console
Unlocked: default
```
4. Выведите все открытые ключи в кошельке по умолчанию:
```sh
cleos wallet keys
```
**Пример вывода**
```console
[
"EOS5VCUBtxS83ZKqVcWtDBF4473P9HyrvnCM9NBc4Upk1C387qmF3"
]
```
5. Выведите все пары открытый/закрытый в кошельке по умолчанию. Будет запрошен пароль:
```sh
cleos wallet private_keys
```
```console
password:
```
6. Введите пароль, заданный при создании кошелька по умолчанию:
```sh
***
```
**Пример вывода**
Если пароль верный, выводятся пары открытый/закрытый:
```console
password: [[
"EOS5VCUBt****************************************F3",
"5JnuuGM1S****************************************4D"
]
]
```
!!! warning "Внимание"
Никогда не раскрывайте закрытые ключи в продуктивной среде.
!!! note "Примечание"
Если команды ничего не выводят, убедитесь, что вы создали пары ключей и импортировали закрытые ключи в кошелёк.
## Итог
Следуя этим шагам, вы получаете список всех открытых ключей и пар открытый/закрытый в кошельке `keosd` по умолчанию.
## Устранение неполадок
При выполнении `cleos wallet open` / `cleos wallet unlock` может появиться такая ошибка CLI:
```sh
cleos wallet open
```
```console
No wallet service listening on ***. Cannot automatically start keosd because keosd was not found.
Failed to connect to keosd at unix:///Users/xxx.xxx/eosio-wallet/keosd.sock; is keosd running?
```
Чтобы устранить ошибку, убедитесь, что на машине запущена утилита `keosd`:
```sh
keosd
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-stake-resource.md
+25
View File
@@ -0,0 +1,25 @@
## Обзор
Здесь приведены примеры, как застейкать NET и/или CPU на свой же аккаунт через `cleos system delegatebw` — чтобы увеличить доступные ресурсы для транзакций и хранения состояния контрактов.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md).
## Шаги
Застейкать 0.01 SYS пропускной способности CPU для `alice`:
```sh
cleos system delegatebw alice alice "0 SYS" "0.01 SYS"
```
Застейкать 0.01 SYS пропускной способности CPU для `alice`:
```sh
cleos system delegatebw alice alice "0.01 SYS" "0 SYS"
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-submit-a-transaction.md
+88
View File
@@ -0,0 +1,88 @@
## Обзор
На этой странице описано, как отправить (push) готовую транзакцию в сеть через `cleos push transaction`: вы формируете JSON транзакции и передаёте его файлом или строкой. Это нужно, когда транзакция уже собрана и её остаётся только подписать и доставить в `nodeos`.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: [что такое транзакция](../../../transactions.md) и как собрать корректный JSON транзакции (поля `expiration`, `ref_block_*`, `actions` и т.д.).
## Шаги
* Создайте JSON-фрагмент с валидной транзакцией, например:
```JSON
{
"expiration": "2019-08-01T07:15:49",
"ref_block_num": 34881,
"ref_block_prefix": 2972818865,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio.token",
"name": "transfer",
"authorization": [{
"actor": "han",
"permission": "active"
}
],
"data": "000000000000a6690000000000ea305501000000000000000453595300000000016d"
}
],
"transaction_extensions": [],
"context_free_data": []
}
```
* Можно также использовать для поля `data` читаемый JSON.
!!! note "Читаемый JSON в `data`"
Если в `data` задан читаемый JSON, `cleos` запрашивает нужные ABI через API `nodeos`; это создаёт дополнительную нагрузку на `nodeos`.
```JSON
{
"expiration": "2019-08-01T07:15:49",
"ref_block_num": 34881,
"ref_block_prefix": 2972818865,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio.token",
"name": "transfer",
"authorization": [{
"actor": "han",
"permission": "active"
}
],
"data": {
"from": "han",
"to": "eosio",
"quantity": "0.0001 SYS",
"memo": "m"
}
}
],
"transaction_extensions": [],
"context_free_data": []
}
```
* Выполните команду:
```sh
cleos push transaction TRX_FILE.json
```
* Отправить транзакцию из JSON:
```sh
cleos push transaction JSON
```
<!---
Link to Push Action API
-->
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-transfer-an-eosio.token-token.md
+19
View File
@@ -0,0 +1,19 @@
## Обзор
Здесь показано, как выполнить перевод основного токена сети через контракт `eosio.token` командой `cleos transfer` — типовая операция между аккаунтами при подключении к рабочей ноде.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Вы переводите токен, созданный контрактом eosio.token, и контракт eosio.token развёрнут в сети, к которой вы подключены.
* Нужны базовые понятия: [транзакции](../../../transactions.md). Имейте в виду: переводы токенов на цепи необратимы.
## Шаги
Чтобы перевести `0.0001 SYS` на аккаунт `bob` с аккаунта `alice`, выполните:
```sh
cleos transfer alice bob "0.0001 SYS" "Hodl!" -p alice@active
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-undelegate-CPU.md
+27
View File
@@ -0,0 +1,27 @@
## Обзор
Здесь показано, как снять делегирование CPU с аккаунта получателя обратно на аккаунт-делегатор (`cleos system undelegatebw`). Снять делегирование может только тот аккаунт, который изначально делегировал ресурс.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md).
## Шаги
Снять делегирование 0.01 SYS пропускной способности CPU с аккаунта `alice` обратно на аккаунт `bob`:
```sh
cleos system undelegatebw bob alice "0 SYS" "0.01 SYS"
```
Вывод должен быть примерно таким:
```console
executed transaction: e7e7edb6c5556de933f9d663fea8b4a9cd56ece6ff2cebf056ddd0835efa6606 184 bytes 452 us
# eosio <= eosio::undelegatebw {"from":"alice","receiver":"bob","unstake_net_quantity":"0.0000 EOS","unstake_cpu_qu...
warning: transaction executed locally, but may not be confirmed by the network yet ]
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-undelegate-NET.md
+27
View File
@@ -0,0 +1,27 @@
## Обзор
Здесь показано, как снять делегирование NET с аккаунта получателя обратно на аккаунт, который изначально делегировал ресурс (`cleos system undelegatebw`). Снять делегирование может только исходный делегатор.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md).
## Шаги
Снять делегирование 0.01 SYS пропускной способности сети с аккаунта `alice` обратно на аккаунт `bob`:
```sh
cleos system undelegatebw bob alice "0 SYS" "0.01 SYS"
```
Вывод должен быть примерно таким:
```console
executed transaction: e7e7edb6c5556de933f9d663fea8b4a9cd56ece6ff2cebf056ddd0835efa6606 184 bytes 452 us
# eosio <= eosio::undelegatebw {"from":"alice","receiver":"bob","unstake_net_quantity":"0.01 EOS","unstake_cpu_qu...
warning: transaction executed locally, but may not be confirmed by the network yet ]
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-unlink-permission.md
+17
View File
@@ -0,0 +1,17 @@
## Обзор
Здесь показано, как убрать привязку разрешения к действию контракта (`cleos set action permission` с `NULL`), вернув для этого действия поведение по умолчанию.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Нужны базовые понятия: [аккаунт и уровни разрешений](../../../accounts.md), а также действие (action) смарт-контракта (см. [транзакции](../../../transactions.md)).
## Шаги
Удалите связанный уровень разрешения у действия `transfer` контракта `hodlcontract`:
```sh
cleos set action permission alice hodlcontract transfer NULL
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-unstake-CPU.md
+27
View File
@@ -0,0 +1,27 @@
## Обзор
Здесь показано, как вывести стейк CPU со своего аккаунта через `cleos system undelegatebw`. Снять делегирование может только тот аккаунт, который изначально делегировал ресурс.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md).
## Шаги
Вывести стейк 0.01 SYS пропускной способности CPU с аккаунта `alice`:
```sh
cleos system undelegatebw alice alice "0.01 SYS" "0 SYS"
```
Вывод должен быть примерно таким:
```console
executed transaction: e7e7edb6c5556de933f9d663fea8b4a9cd56ece6ff2cebf056ddd0835efa6606 184 bytes 452 us
# eosio <= eosio::undelegatebw {"from":"alice","receiver":"alice","unstake_net_quantity":"0.0000 EOS","unstake_cpu_qu...
warning: transaction executed locally, but may not be confirmed by the network yet ]
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-unstake-NET.md
+27
View File
@@ -0,0 +1,27 @@
## Обзор
Здесь показано, как вывести стейк NET со своего аккаунта через `cleos system undelegatebw`. Снять делегирование может только тот аккаунт, который изначально делегировал ресурс.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* Нужны базовые понятия: [аккаунт](../../../accounts.md) и [системные ресурсы NET/CPU](../../../system-resources.md).
## Шаги
Вывести стейк 0.01 SYS пропускной способности сети с аккаунта `alice`:
```sh
cleos system undelegatebw alice alice "0 SYS" "0.01 SYS"
```
Вывод должен быть примерно таким:
```console
executed transaction: e7e7edb6c5556de933f9d663fea8b4a9cd56ece6ff2cebf056ddd0835efa6606 184 bytes 452 us
# eosio <= eosio::undelegatebw {"from":"alice","receiver":"alice","unstake_net_quantity":"0.01 EOS","unstake_cpu_qu...
warning: transaction executed locally, but may not be confirmed by the network yet ]
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/how-to-vote.md
+28
View File
@@ -0,0 +1,28 @@
## Обзор
Здесь показано, как отдать голос за одного или нескольких производителей блоков через `cleos system voteproducer` в сети с классическим контрактом `eosio.system`.
## Перед началом
* Установлена поддерживаемая версия `cleos`.
* Развёрнуты и используются эталонные системные контракты из репозитория `eosio.contracts` для управления системными ресурсами.
* Полезно знать, кто такие производители блоков и как в вашей сети устроено голосование; общий контекст — в разделах [ноды и делегаты](../../../nodes.md) и [протоколы](../../../protocols.md).
* Разблокируйте кошелёк.
## Шаги
Если вы голосуете за `blockproducer1` и `blockproducer2` с аккаунта `eosiotestts2`, выполните:
```sh
cleos system voteproducer prods eosiotestts2 blockproducer1 blockproducer2
```
Вывод должен быть примерно таким:
```console
executed transaction: 2d8b58f7387aef52a1746d7a22d304bbbe0304481d7751fc4a50b619df62676d 128 bytes 374 us
# eosio <= eosio::voteproducer {"voter":"eosiotestts2","proxy":"","producers":["blockproducer1","blockproducer2"]}
```
docs/documentation/blockchain/coopos/02_cleos/02_how-to-guides/index.md
+29
View File
@@ -0,0 +1,29 @@
# Руководства по cleos (how-to)
Ниже — пошаговые заметки по **cleos**.
- [Подключение к сети](how-to-connect-a-specific-network.md)
- [Создание кошелька](how-to-create-a-wallet.md)
- [Создание пары ключей](how-to-create-key-pairs.md)
- [Список пар ключей](how-to-list-all-key-pairs.md)
- [Импорт ключа](how-to-import-a-key.md)
- [Создание аккаунта](how-to-create-an-account.md)
- [Информация об аккаунте](how-to-get-account-information.md)
- [Мультисиг-аккаунт](how-to-config-a-multisig-account.md)
- [Связать разрешение](how-to-link-permission.md)
- [Отвязать разрешение](how-to-unlink-permission.md)
- [Информация о блоке](how-to-get-block-information.md)
- [Информация о транзакции](how-to-get-transaction-information.md)
- [Таблицы контракта](how-to-get-tables-information.md)
- [Отправка транзакции](how-to-submit-a-transaction.md)
- [Перевод токена eosio.token](how-to-transfer-an-eosio.token-token.md)
- [Покупка RAM](how-to-buy-ram.md)
- [Делегирование NET](how-to-delegate-net-resource.md)
- [Делегирование CPU](how-to-delegate-CPU-resource.md)
- [Снятие делегирования NET](how-to-undelegate-NET.md)
- [Снятие делегирования CPU](how-to-undelegate-CPU.md)
- [Вывод стейка NET](how-to-unstake-NET.md)
- [Вывод стейка CPU](how-to-unstake-CPU.md)
- [Стейк ресурса](how-to-stake-resource.md)
- [Развёртывание контракта](how-to-deploy-a-smart-contract.md)
- [Голосование](how-to-vote.md)
docs/documentation/blockchain/coopos/02_cleos/03_command-reference/convert/index.md
+8
View File
@@ -0,0 +1,8 @@
## Описание
Упаковка и распаковка транзакций
## Подкоманды
- [pack_transaction](pack_transaction.md) — из обычного подписанного JSON в упакованный вид
- [unpack_transaction](unpack_transaction.md) — из упакованного в обычный подписанный JSON
- [pack_action_data](pack_action_data.md) — из JSON данных действия в упакованный вид
- [unpack_action_data](unpack_action_data.md) — из упакованных данных действия в JSON
docs/documentation/blockchain/coopos/02_cleos/03_command-reference/convert/pack_action_data.md
+23
View File
@@ -0,0 +1,23 @@
## Описание
Из JSON данных действия в упакованный вид
## Позиционные параметры
- `account` _TEXT_ — аккаунт, на котором развёрнут контракт
- `name` _TEXT_ — имя вызываемого действия
- `unpacked_action_data` _TEXT_ — данные действия в JSON
## Опции
- `-h,--help` — вывести справку и выйти
## Использование
```sh
cleos convert pack_action_data eosio unlinkauth '{"account":"test1", "code":"test2", "type":"eosioeosio"}'
```
## Вывод
```console
000000008090b1ca000000000091b1ca000075982aea3055
```
docs/documentation/blockchain/coopos/02_cleos/03_command-reference/convert/pack_transaction.md
+50
View File
@@ -0,0 +1,50 @@
## Описание
Из обычного подписанного JSON в упакованный вид
## Позиционные параметры
- `transaction` _TEXT_ — обычная подписанная транзакция в JSON (строка)
## Опции
- `-h,--help` — вывести справку и выйти
- `--pack-action-data` — упаковать все данные действий внутри транзакции (требуется обращение к `nodeos`)
## Использование
```sh
cleos convert pack_transaction '{
"expiration": "2018-08-02T20:24:36",
"ref_block_num": 14207,
"ref_block_prefix": 1438248607,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio",
"name": "newaccount",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": "0000000000ea305500a6823403ea30550100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d8010000000100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d801000000"
}
],
"transaction_extensions": []
}'
```
## Вывод
```json
{
"signatures": [],
"compression": "none",
"packed_context_free_data": "",
"packed_trx": "8468635b7f379feeb95500000000010000000000ea305500409e9a2264b89a010000000000ea305500000000a8ed3232660000000000ea305500a6823403ea30550100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d8010000000100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d80100000000"
}
```
docs/documentation/blockchain/coopos/02_cleos/03_command-reference/convert/unpack_action_data.md
+28
View File
@@ -0,0 +1,28 @@
## Описание
Из упакованных данных действия в JSON
## Позиционные параметры
- `account` _TEXT_ — аккаунт, на котором развёрнут контракт
- `name` _TEXT_ — имя вызываемого действия
- `packed_action_data` _TEXT_ — данные действия в виде упакованной hex-строки
## Опции
- `-h,--help` — вывести справку и выйти
## Использование
```sh
cleos convert unpack_action_data eosio unlinkauth 000000008090b1ca000000000091b1ca000075982aea3055
```
## Вывод
```json
{
"account": "test1",
"code": "test2",
"type": "eosioeosio"
}
```
docs/documentation/blockchain/coopos/02_cleos/03_command-reference/convert/unpack_transaction.md
+57
View File
@@ -0,0 +1,57 @@
## Описание
Из упакованного вида в обычный подписанный JSON
## Позиционные параметры
- `transaction` _TEXT_ — JSON упакованной транзакции (строка с полями `packed_trx` и при необходимости `compression`)
## Опции
- `-h,--help` — вывести справку и выйти
- `--unpack-action-data` — распаковать все данные действий внутри транзакции (требуется обращение к `nodeos`)
## Использование
```sh
cleos convert unpack_transaction '{
"signatures": [
"SIG_K1_KmRbWahefwxs6uyCGNR6wNRjw7cntEeFQhNCbyg8S92Kbp7zdSSVGTD2QS7pNVWgcU126zpxaBp9CwUxFpRwSnfkjd46bS"
],
"compression": "none",
"packed_context_free_data": "",
"packed_trx": "8468635b7f379feeb95500000000010000000000ea305500409e9a2264b89a010000000000ea305500000000a8ed3232660000000000ea305500a6823403ea30550100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d8010000000100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d80100000000"
}'
```
## Вывод
```json
{
"expiration": "2018-08-02T20:24:36",
"ref_block_num": 14207,
"ref_block_prefix": 1438248607,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio",
"name": "newaccount",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": "0000000000ea305500a6823403ea30550100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d8010000000100000001000240cc0bf90a5656c8bb81f0eb86f49f89613c5cd988c018715d4646c6bd0ad3d801000000"
}
],
"transaction_extensions": [],
"signatures": [
"SIG_K1_KmRbWahefwxs6uyCGNR6wNRjw7cntEeFQhNCbyg8S92Kbp7zdSSVGTD2QS7pNVWgcU126zpxaBp9CwUxFpRwSnfkjd46bS"
],
"context_free_data": []
}
```

Some files were not shown because too many files have changed in this diff Show More