Merge pull request #99 from nspcc-dev/update-and-fix

Update autogenerated and fix chains

01-arch/00-overview.md

@@ -9,14 +9,14 @@ NeoFS heavily relies on the Neo Blockchain and its features. This allows NeoFS n
 
 The \Gls{mainnet} hosts a NeoFS [Native Contract](https://medium.com/neo-smart-economy/native-contracts-in-neo-3-0-e786100abf6e) concerned with user deposits and withdrawals, network settings, and other maintenance operations such as listing the keys of trusted nodes.
 
-To simplify accounting operations, lessen Main Net burden, and reduce the overall network maintenance costs, NeoFS utilizes an N3-based [sidechain](https://en.wikipedia.org/wiki/Blockchain#Types). The NeoFS Sidechain runs Smart Contracts which control the NeoFS network structure, user settlements, balances, and other frequently changing data.
+To simplify accounting operations, lessen mainnet burden, and reduce the overall network maintenance costs, NeoFS utilizes an N3-based [sidechain](https://en.wikipedia.org/wiki/Blockchain#Types) aka "FS chain". FS chain runs smart contracts which control the NeoFS network structure, user settlements, balances, and other frequently changing data.
 
 There are two types of NeoFS nodes. They are Storage nodes and Inner Ring nodes.
 
-The first type is responsible for receiving data from a user, reliably storing it as required by the storage policy, and providing access to the data according to the applicable \glspl{acl}. Such storage nodes are coordinated with Smart Contracts from the Sidechain.
+The first type is responsible for receiving data from a user, reliably storing it as required by the storage policy, and providing access to the data according to the applicable \glspl{acl}. Such storage nodes are coordinated with smart contracts from the FS chain.
 
 The second type does not store user data. Inner Ring nodes monitor the NeoFS network health, aggregate Storage Nodes reputation ratings, and perform data
-auditing, issuing penalties and bounties depending on the audit results. Inner Ring nodes listen for both Main Net and Sidechain, providing a trusted and
+auditing, issuing penalties and bounties depending on the audit results. Inner Ring nodes listen for both mainnet and FS chain, providing a trusted and
 reliable way of data synchronization between the two Blockchains.
 
 Each Storage node in the system has a set of key-value attributes describing node properties such as it's geographical location, reputation rating, number of replicas, number of nodes, presence of SSD drives, etc. Inner Ring nodes generate a Network Map --- a multi-graph structure which enables Storage nodes to be selected and grouped based on those attributes.

01-arch/07-acl.md

@@ -6,7 +6,7 @@ NeoFS solves this by using \Gls{acl} rules from the combination of sources:
 
 - Basic ACL in the container structure,
 - BearerToken ACL rules in the request,
-- Extended ACL rules in the SideChain smart contract.
+- Extended ACL rules in the FS chain smart contract.
 
 \Glspl{acl} specifies a set of actions that a particular user or a group of users can do with objects in the container. Each request coming through a storage node gets verified against those rules and rejected if the requests's action is not allowed.
 
@@ -74,13 +74,13 @@ Non-final -- Extended ACL can be set:
 
 ### Extended ACL
 
-Extended ACL is stored in the container smart contract in NeoFS Sidechain. This means it can be changed during container lifetime and there will be only one latest version of it in use. Only the container owner, or the bearer of a SessionToken with a Container context signed by the container owner, can change the Extended ACL rules. Since it is stored in a form of a stable serialized protobuf structure, eACL table can be only replaced with a new version, not altered or changed in-place in any way.
+Extended ACL is stored in the container smart contract in FS chain. This means it can be changed during container lifetime and there will be only one latest version of it in use. Only the container owner, or the bearer of a SessionToken with a Container context signed by the container owner, can change the Extended ACL rules. Since it is stored in a form of a stable serialized protobuf structure, eACL table can be only replaced with a new version, not altered or changed in-place in any way.
 
 Extended ACL can only specify Basic ACL rules and make them more restitutive, but it can never ease them. Extended ACL rules can never conflict with Basic ACL rules or cancel them. If something is denied at Basic ACL level, it can never be allowed again by eACL. If Basic ACL contains Allow, eACL may specify the rule to a finite list of allowed keys and Deny all others. If Basic ACL already contains Deny, eACL can do nothing. Deny in Basic ACL cannot be changed to Allow in eACL. Therefore, the records with denied `GET`, `GETRANGE`, `PUT`, `SEARCH`, `HEAD` for `System` target must be ignored. This reduces to ignoring any `System` target rules.
 
 When a user creates a container with the F-bit of Basic ACL set to 0, they do not need to settle the rules immediately. For a non-existing Extended ACL request, Container contract will return a null byte array. It will be interpreted as a table with no rules.
 
-To get the latest eACL version, a Storage Node needs to request it via RPC from the SideChain node. If an eACL can't be retrieved, the access permissions check fails.
+To get the latest eACL version, a Storage Node needs to request it via RPC from the FS chain node. If an eACL can't be retrieved, the access permissions check fails.
 
 Extended ACL rules get processed on-by-one, from the beginning of the table, based on the request operation, until matching the rule found. It means that there is no separate rule for setting denying or allowing policy. Final fallback rules must be provided by the user, if needed.
 

05-audit/02-game.md

@@ -11,15 +11,15 @@ At the second stage, it is necessary to make sure nodes are honest and do not fa
 
 Combining the fact of nodes being able to reconstruct the Storage Group's composite hash and the fact of nodes honest behavior, the system can consider that the data is safely stored, not corrupted, and available with a high probability.
 
-In the case of a successful data audit result, the Inner Ring nodes initiate microtransactions between the accounts of the data owner and the owner of the storage node invoking the smart contract in the NeoFS N3 Sidechain.
+In the case of a successful data audit result, the Inner Ring nodes initiate microtransactions between the accounts of the data owner and the owner of the storage node invoking the smart contract in the FS chain.
 
 ![Data Audit](pic/1.png)
 
 ### Audit tasks distribution
 
 InnerRing nodes select containers to audit from a list of all containers in the network, forming a ring of containers and taking an offset shackle with its number among InnerRing nodes and by audit number.
 
-Each epoch, Inner Ring node performs data audit. One audit task is a one storage group to check. Storage groups from one container get merged into a single audit result structure that will be saved in the Audit smart contract in NeoFS Sidechain.
+Each epoch, Inner Ring node performs data audit. One audit task is a one storage group to check. Storage groups from one container get merged into a single audit result structure that will be saved in the Audit smart contract in FS chain.
 
 Upon each new Epoch notification, Inner Ring node must:
 

06-blockchain/00-intro.md

@@ -21,7 +21,7 @@ Meanwhile, NeoFS contracts:
 - manage the economy;
 - control the governance of the NeoFS network.
 
-## Mainchain and sidechain
+## Main chain and FS chain
 
 Business logic of smart contracts is executed at contract method invocations from Inner Ring nodes. They are either multisigned transactions or regular transactions. However, these invocations are paid and require \Gls{GAS} for computation. If data owners are charged for these computations, it will be economically impractical for them to use NeoFS.
 
@@ -30,11 +30,11 @@ To solve this problem, we divide smart contract operations into two types:
 - financial transactions and governance,
 - storage system associated operations.
 
-The first type of operations should be executed in the mainchain. These operations are quite rare and they require GAS as a payment asset. The mainchain for NeoFS is \Gls{mainnet}. Thus, `NeoFS` contract is deployed in the mainchain. It allows to make a deposit, update network config, and reregister the Inner Ring candidate node. The mainchain also manages \Gls{AlphabetNodes} of the Inner Ring using the \Gls{RoleManagement}.
+The first type of operations should be executed in the main chain. These operations are quite rare and they require GAS as a payment asset. The main chain for NeoFS is \Gls{mainnet}. Thus, `NeoFS` contract is deployed in the main chain. It allows to make a deposit, update network config, and reregister the Inner Ring candidate node. The main chain also manages \Gls{AlphabetNodes} of the Inner Ring using the \Gls{RoleManagement}.
 
-The second type of operations can be executed on an additional chain that we call the sidechain. Sidechain is the Neo blockchain with a different network configuration. Validator nodes of the sidechain are Alphabet nodes of the Inner Ring. Sidechain GAS is managed by Alphabet contracts and should be used only for network maintenance and NeoFS contract execution. Sidechain has `Alphabet`, `Audit`, `Balance`, `Container`, `NeoFSID`, `Netmap`, `Reputation` contracts. No other contracts unrelated to NeoFS can be deployed in the sidechain.
+The second type of operations can be executed on an additional chain that we call the FS chain. FS chain is a Neo N3 blockchain with a different network configuration. Validator nodes of FS chain are Alphabet nodes of the Inner Ring. FS chain GAS is managed by Alphabet contracts and should be used only for network maintenance and NeoFS contract execution. FS chain has `Alphabet`, `Audit`, `Balance`, `Container`, `NeoFSID`, `Netmap`, `Reputation` contracts. No other contracts unrelated to NeoFS can be deployed in the FS chain.
 
-Inner Ring nodes synchronize states of mainchain and sidechain contracts by listening to the notification events and reacting to them.
+Inner Ring nodes synchronize states of main chain and FS chain contracts by listening to the notification events and reacting to them.
 
 ## Notary service
 
@@ -44,6 +44,6 @@ To make decisions according to the consensus, transactions must be multisigned b
 - inability to calculate the exact price of a transaction, which leads to an increased cost of execution;
 - the contract logic complication.
 
-While in the sidechainб GAS is used only for utility purposes and invocation prices can be mostly ignored, Alphabet nodes of the Inner Ring in the mainchain use a real GAS asset to do withdrawal operation. High execution cost of such operation leads to high withdrawal commissions.
+While in FS chain GAS is used only for utility purposes and invocation prices can be mostly ignored, Alphabet nodes of the Inner Ring in the mainnet use a real GAS asset to do withdrawal operation. High execution cost of such operation leads to high withdrawal commissions.
 
-To solve this issue, NeoFS supports [notary service](https://github.com/neo-project/neo/issues/1573#issuecomment-704874472). The notary service allows to build multisigned transactions natively in the blockchain. Thus, the number of transactions and their costs are reduced, contract source code is simplified. Special `proxy` (in the sidechain) and `processing` (in the mainchain) contracts can pay for invocation instead of Alphabet nodes of the Inner Ring. With these contracts, it becomes easier to monitor and control the NeoFS economy.
+To solve this issue, NeoFS supports [notary service](https://github.com/neo-project/neo/issues/1573#issuecomment-704874472). The notary service allows to build multisigned transactions natively in the blockchain. Thus, the number of transactions and their costs are reduced, contract source code is simplified. Special `proxy` (in FS chain) and `processing` (in the main chain) contracts can pay for invocation instead of Alphabet nodes of the Inner Ring. With these contracts, it becomes easier to monitor and control the NeoFS economy.