New Crowdin updates

docs_i18n/Chinese Simplified/AVM_Design.md

@@ -0,0 +1,53 @@
+---
+id: AVM_Design
+title: AVM design rationale
+sidebar_label: AVM design rationale
+---
+
+This document outlines the design rationale for the Arbitrum Virtual Machine (AVM) architecture.
+
+The starting point for the AVM design is the Ethereum Virtual Machine (EVM). Because Arbitrum aims to efficiently execute programs written or compiled for EVM, Arbitrum uses many aspects of EVM unchanged. For example, AVM adopts EVM's basic integer datatype (a 256-bit big-endian unsigned integer), as well as the instructions that operate on EVM integers.
+
+Differences between AVM and EVM are motivated by the needs of Arbitrum's Layer 2 protocol and Arbitrum's use of a multi-round challenge protocol to resolve disputes.
+
+## Execution vs. proving
+
+Arbitrum, unlike EVM and similar architectures, needs to support both execution (advancing the state of a computation by local emulation) and proving (convincing an L1 contract or other trusted party that a claim about execution is correct). EVM-based systems resolve disputes by re-executing the disputed code, whereas Arbitrum relies on a challenge protocol that leads to an eventual proof.
+
+We want execution to be optimized for speed in a local, trusted environment, because local execution is the common case. Proving, on the other hand, will be needed less often but must still be efficient enough to be viable even in a congested L1 system. The system will rarely need to prove, but it always needs to be _prepared_ to prove. The logical separation of execution from proving allows execution speed to be optimized more aggressively in the common case where proving turns out not to be needed.
+
+## ArbOS
+
+Another difference in requirements is that Arbitrum uses ArbOS, a "operating system" that runs at Layer 2. ArbOS controls the execution of separate contracts to isolate them from each other and track their resource usage.
+
+Supporting these functions in Layer 2 trusted software, rather than building them in to the L1-enforced rules of the architecture as Ethereum does, offers significant advantages in cost because these operations can benefit from the lower cost of computation and storage at Layer 2, instead of having to manage those resources as part of the Layer 1 EthBridge contract. Having a trusted operating system at Layer 2 also has significant advantages in flexibility, because Layer 2 code is easier to evolve, or to customize for a particular chain, than a Layer-1 enforced VM architecture would be.
+
+The use of a Layer 2 trusted operating system does require some support in the architecture, for example to allow the OS to limit and track resource usage by contracts.
+
+## Supporting Merkleization
+
+Any Layer 2 protocol that relies on assertions and dispute resolution (which includes at least all rollup protocols) must define a rule for Merkle-hashing the full state of the virtual machine. That rule must be part of the architecture definition because it is relied upon in resolving disputes.
+
+It must also be reasonably efficient to maintain the Merkle hash and/or recompute it when needed. This affects how the architecture structures its memory, for example. Any storage structure that is large and mutable will be relatively expensive to Merkleize, and an algorithm for Merkleizing it must be part of the architecture specification.
+
+The AVM architecture responds to this challenge by having only bounded-size, immutable memory objects ("Tuples"), which can include other Tuples by reference. Tuples cannot be modified in-place but there is an instruction to copy a Tuple with a modification. This allows the construction of tree structures which can behave like a large flat memory. Applications can use functionalities such as large flat arrays, key-value stores, and so on, by accessing libraries that use Tuples internally.
+
+The semantics of Tuples make it impossible to create cyclic structures of Tuples, so an AVM implementation can safely manage Tuples by using reference-counted, immutable structures. The hash of each Tuple value need only be computed once, because the contents are immutable.
+
+## Code organization: Codepoints
+
+The conventional organization of code is to store a linear array of instructions, and keep a program counter pointing to the next instruction that will be executed. With this conventional approach, proving an instruction of execution requires logarithmic time and space, because a Merkle proof must be presented to prove which instruction is under the current PC.
+
+The AVM uses this conventional approach for execution, but it adds a feature that makes proving and proof-checking require constant time and space. The CodePoint for the instruction at some PC value is the pair (instruction at PC, Hash(CodePoint at PC+1)). (If there is no CodePoint at PC+1, then zero is used instead.)
+
+For proving purposes, the "program counter" is replaced by a "current CodePoint hash" value, which is part of the machine state. The preimage of this hash will contain the current instruction, and the hash of the following codepoint, which is everything the verifier needs to verify what the instruction is and what the current CodePoint hash value will be after the instruction, if the instruction isn't a Jump.
+
+All jump instructions use jump destinations that are CodePoints, so a proof about execution of a jump instruction also has immediately at hand not only the PC that is being jumped to, but also what the contents of the "current CodePoint hash" register will be after the jump executes. In every case, proof and verification requires constant time and space.
+
+In normal execution (when proving is not required), implementations will typically just use PC values as on a conventional architecture. However, when a proof is needed, the prover can use a lookup table to get the CodePoint hashes corresponding to any relevant PCs.
+
+## Support for ArbOS
+
+ArbOS, running at Layer 2, isolates untrusted programs from each other, tracks and limits their resource usage, and manages the economic model that collects fees from users to fund the operation of a chain's validators.
+
+In support of this, the AVM includes instructions to support saving and restoring the machine's stack, managing machine registers that track resource usage, and receives messages from external callers. These instructions are used by ArbOS itself, but ArbOS ensures that they will never appear in untrusted code.

docs_i18n/Chinese Simplified/AbsRollupUserFacet.md

@@ -0,0 +1,128 @@
+---
+title: AbsRollupUserFacet.sol Spec
+id: AbsRollupUserFacet
+---
+
+### `onlyValidator()`
+
+### `initialize(address _stakeToken)` (public)
+
+### `rejectNextNode(address stakerAddress)` (external)
+
+Reject the next unresolved node
+
+- `stakerAddress`: Example staker staked on sibling
+
+### `confirmNextNode(bytes32 beforeSendAcc, bytes sendsData, uint256[] sendLengths, uint256 afterSendCount, bytes32 afterLogAcc, uint256 afterLogCount)` (external)
+
+Confirm the next unresolved node
+
+- `beforeSendAcc`: Accumulator of the AVM sends from the beginning of time up to the end of the previous confirmed node
+
+- `sendsData`: Concatenated data of the sends included in the confirmed node
+
+- `sendLengths`: Lengths of the included sends
+
+- `afterSendCount`: Total number of AVM sends emitted from the beginning of time after this node is confirmed
+
+- `afterLogAcc`: Accumulator of the AVM logs from the beginning of time up to the end of this node
+
+- `afterLogCount`: Total number of AVM logs emitted from the beginning of time after this node is confirmed
+
+### `stakeOnExistingNode(uint256 nodeNum, bytes32 nodeHash)` (external)
+
+Move stake onto an existing node
+
+- `nodeNum`: Inbox of the node to move stake to. This must by a child of the node the staker is currently staked on
+
+- `nodeHash`: Node hash of nodeNum (protects against reorgs)
+
+### `stakeOnNewNode(bytes32 expectedNodeHash, bytes32[3][2] assertionBytes32Fields, uint256[4][2] assertionIntFields, uint256 beforeProposedBlock, uint256 beforeInboxMaxCount, bytes sequencerBatchProof)` (external)
+
+Move stake onto a new node
+
+- `expectedNodeHash`: The hash of the node being created (protects against reorgs)
+
+- `assertionBytes32Fields`: Assertion data for creating
+
+- `assertionIntFields`: Assertion data for creating
+
+### `returnOldDeposit(address stakerAddress)` (external)
+
+Refund a staker that is currently staked on or before the latest confirmed node
+
+Since a staker is initially placed in the latest confirmed node, if they don't move it a griefer can remove their stake. It is recomended to batch together the txs to place a stake and move it to the desired node.
+
+- `stakerAddress`: Address of the staker whose stake is refunded /
+
+### `reduceDeposit(uint256 target)` (external)
+
+Reduce the amount staked for the sender
+
+- `target`: Target amount of stake for the staker. If this is below the current minimum, it will be set to minimum instead /
+
+### `createChallenge(address payable[2] stakers, uint256[2] nodeNums, bytes32[2] executionHashes, uint256[2] proposedTimes, uint256[2] maxMessageCounts)` (external)
+
+Start a challenge between the given stakers over the node created by the first staker assuming that the two are staked on conflicting nodes
+
+- `stakers`: Stakers engaged in the challenge. The first staker should be staked on the first node
+
+- `nodeNums`: Nodes of the stakers engaged in the challenge. The first node should be the earliest and is the one challenged
+
+- `executionHashes`: Challenge related data for the two nodes
+
+- `proposedTimes`: Times that the two nodes were proposed
+
+- `maxMessageCounts`: Total number of messages consumed by the two nodes /
+
+### `completeChallenge(address winningStaker, address losingStaker)` (external)
+
+Inform the rollup that the challenge between the given stakers is completed
+
+completeChallenge isn't pausable since in flight challenges should be allowed to complete or else they could be forced to timeout
+
+- `winningStaker`: Address of the winning staker
+
+- `losingStaker`: Address of the losing staker /
+
+### `removeZombie(uint256 zombieNum, uint256 maxNodes)` (external)
+
+Remove the given zombie from nodes it is staked on, moving backwords from the latest node it is staked on
+
+- `zombieNum`: Index of the zombie to remove
+
+- `maxNodes`: Maximum number of nodes to remove the zombie from (to limit the cost of this transaction) /
+
+### `removeOldZombies(uint256 startIndex)` (public)
+
+Remove any zombies whose latest stake is earlier than the first unresolved node
+
+- `startIndex`: Index in the zombie list to start removing zombies from (to limit the cost of this transaction) /
+
+### `requiredStake(uint256 blockNumber, uint256 firstUnresolvedNodeNum, uint256 latestNodeCreated) → uint256` (public)
+
+Calculate the current amount of funds required to place a new stake in the rollup
+
+If the stake requirement get's too high, this function may start reverting due to overflow, but that only blocks operations that should be blocked anyway
+
+**Returns**: The: current minimum stake requirement /
+
+### `currentRequiredStake() → uint256` (public)
+
+### `countStakedZombies(contract INode node) → uint256` (public)
+
+Calculate the number of zombies staked on the given node
+
+This function could be uncallable if there are too many zombies. However, removeZombie and removeOldZombies can be used to remove any zombies that exist so that this will then be callable
+
+- `node`: The node on which to count staked zombies
+
+**Returns**: The: number of zombies staked on the node /
+
+### `requireUnresolvedExists()` (public)
+
+Verify that there are some number of nodes still unresolved /
+
+### `requireUnresolved(uint256 nodeNum)` (public)
+
+### `withdrawStakerFunds(address payable destination) → uint256` (external)

docs_i18n/Chinese Simplified/Aggregator.md

@@ -0,0 +1,11 @@
+---
+id: Aggregator
+title: Aggregators in Arbitrum
+sidebar_label: Aggregators
+---
+
+聚合器与以太坊网络中的节点有着相同的功能， 客户端可以使用API向聚合器发送远程调用请求（RPCs）以和Arbitrum网络交互。 与以太坊节点一样，之后聚合器将会向EthBridge发送请求并且将交易结果返回给客户端。
+
+大多数客户端可以使用聚合器来提交他们Arbitrum的交易，即使这不是必要的。 至于网络中可以存在多少聚合器，谁可以成为聚合器都没有数量限制。
+
+为了提高效率，集合器通常将多个客户交易合并成一个单一的信息，并提交给Arbitrum网络。

docs_i18n/Chinese Simplified/ArbAddressTable.md

@@ -0,0 +1,56 @@
+---
+title: ArbAddressTable.sol Spec
+id: ArbAddressTable
+---
+
+Precompiled contract that exists in every Arbitrum chain at 0x0000000000000000000000000000000000000066. Allows registering / retrieving addresses at uint indices, saving calldata.
+
+### `register(address addr) → uint256` (external)
+
+Register an address in the address table
+
+- `addr`: address to register
+
+**Returns**: index: of the address (existing index, or newly created index if not already registered)
+
+### `lookup(address addr) → uint256` (external)
+
+- `addr`: address to lookup
+
+**Returns**: index: of an address in the address table (revert if address isn't in the table)
+
+### `addressExists(address addr) → bool` (external)
+
+Check whether an address exists in the address table
+
+- `addr`: address to check for presence in table
+
+**Returns**: true: if address is in table
+
+### `size() → uint256` (external)
+
+**Returns**: size: of address table (= first unused index)
+
+### `lookupIndex(uint256 index) → address` (external)
+
+- `index`: index to lookup address
+
+**Returns**: address: at a given index in address table (revert if index is beyond end of table)
+
+### `decompress(bytes buf, uint256 offset) → address, uint256` (external)
+
+read a compressed address from a bytes buffer
+
+- `buf`: bytes buffer containing an address
+
+- `offset`: offset of target address
+
+**Returns**: resulting: address and updated offset into the buffer (revert if buffer is too short)
+
+### `compress(address addr) → bytes` (external)
+
+compress an address and return the result
+
+- `addr`: address to comppress
+
+**Returns**: compressed: address bytes

docs_i18n/Chinese Simplified/ArbAggregator.md

@@ -0,0 +1,16 @@
+---
+title: ArbAggregator.sol Spec
+id: ArbAggregator
+---
+
+### `getPreferredAggregator(address addr) → address, bool` (external)
+
+### `setPreferredAggregator(address prefAgg)` (external)
+
+### `getDefaultAggregator() → address` (external)
+
+### `setDefaultAggregator(address newDefault)` (external)
+
+### `getFeeCollector(address aggregator) → address` (external)
+
+### `setFeeCollector(address aggregator, address newFeeCollector)` (external)

docs_i18n/Chinese Simplified/ArbBLS.md

@@ -0,0 +1,8 @@
+---
+title: ArbBLS.sol Spec
+id: ArbBLS
+---
+
+### `register(uint256 x0, uint256 x1, uint256 y0, uint256 y1)` (external)
+
+### `getPublicKey(address addr) → uint256, uint256, uint256, uint256` (external)

docs_i18n/Chinese Simplified/ArbBatchTokenMover.md

@@ -0,0 +1,8 @@
+---
+title: ArbBatchTokenMover.sol Spec
+id: ArbBatchTokenMover
+---
+
+### `withdrawInBatch(uint256 amount)` (external)
+
+### `exitToL1()` (external)

docs_i18n/Chinese Simplified/ArbFunctionTable.md

@@ -0,0 +1,10 @@
+---
+title: ArbFunctionTable.sol Spec
+id: ArbFunctionTable
+---
+
+### `upload(bytes buf)` (external)
+
+### `size(address addr) → uint256` (external)
+
+### `get(address addr, uint256 index) → uint256, bool, uint256` (external)