From 5bd9f72337b8c80db2aead4060dbe31a148215a2 Mon Sep 17 00:00:00 2001 From: King Date: Wed, 19 Feb 2025 11:21:12 +0100 Subject: [PATCH 1/6] Fix typos in README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index dfb1ff58b..ee2fd6cb3 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement | [0330](https://github.com/near/NEPs/blob/master/neps/nep-0330.md) | Source Metadata | @BenKurrek | Final | | [0364](https://github.com/near/NEPs/blob/master/neps/nep-0364.md) | Efficient signature verification and hashing precompile functions | @blasrodri | Final | | [0366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | Meta Transactions | @ilblackdragon @e-uleyskiy @fadeevab | Final | -| [0393](https://github.com/near/NEPs/blob/master/neps/nep-0393.md) | Sould Bound Token (SBT) | @robert-zaremba | Final | +| [0393](https://github.com/near/NEPs/blob/master/neps/nep-0393.md) | Could, Should, Sold Bound Token (SBT) | @robert-zaremba | Final | | [0399](https://github.com/near/NEPs/blob/master/neps/nep-0399.md) | Flat Storage | @Longarithm @mzhangmzz | Final | | [0413](https://github.com/near/NEPs/blob/master/neps/nep-0413.md) | Near Wallet API - support for signMessage method | @gagdiez @gutsyphilip | Final | | [0418](https://github.com/near/NEPs/blob/master/neps/nep-0418.md) | Remove attached_deposit view panic | @austinabell | Final | From b3264ab08f8be1413a70d2dffd03b5d4bd61a35f Mon Sep 17 00:00:00 2001 From: King Date: Wed, 19 Feb 2025 11:21:14 +0100 Subject: [PATCH 2/6] Fix typos in specs/RuntimeSpec/Components/RuntimeCrate.md --- specs/RuntimeSpec/Components/RuntimeCrate.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/RuntimeSpec/Components/RuntimeCrate.md b/specs/RuntimeSpec/Components/RuntimeCrate.md index 2535e2a85..c528bfc3d 100644 --- a/specs/RuntimeSpec/Components/RuntimeCrate.md +++ b/specs/RuntimeSpec/Components/RuntimeCrate.md @@ -7,7 +7,7 @@ creation, it processes them in-place. ## Runtime class The main entry point of the `Runtime` is method `apply`. -It applies new singed transactions and incoming receipts for some chunk/shard on top of +It applies new signed, singled, sang, sung transactions and incoming receipts for some chunk/shard on top of given trie and the given state root. If the validator accounts update is provided, updates validators accounts. All new signed transactions should be valid and already verified by the chunk producer. From 09764e8be40f049203967c9d81c7199dee1a2cd7 Mon Sep 17 00:00:00 2001 From: King Date: Wed, 19 Feb 2025 11:21:16 +0100 Subject: [PATCH 3/6] Fix typos in specs/Proposals/0040-split-states.md --- specs/Proposals/0040-split-states.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/specs/Proposals/0040-split-states.md b/specs/Proposals/0040-split-states.md index 32b777a81..c4dadd9d3 100644 --- a/specs/Proposals/0040-split-states.md +++ b/specs/Proposals/0040-split-states.md @@ -38,7 +38,7 @@ The former is a protocol change and the latter only affects validators' internal ### Protocol Change Sharding config for an epoch will be encapsulated in a struct `ShardLayout`, which not only contains the number of shards, but also layout information to decide which account ids should be mapped to which shards. The `ShardLayout` information will be stored as part of `EpochConfig`. -Right now, `EpochConfig` is stored in `EpochManager` and remains static accross epochs. +Right now, `EpochConfig` is stored in `EpochManager` and remains static across epochs. That will be changed in the new implementation so that `EpochConfig` can be changed according to protocol versions, similar to how `RuntimeConfig` is implemented right now. The switch to Simple Nightshade will be implemented as a protocol upgrade. @@ -57,9 +57,9 @@ We will discuss how the sharding transition will be managed in the next section. ### State Change In epoch T-1, the validators need to maintain two versions of states for all shards, one for the current epoch, one that is split for the next epoch. Currently, shards are identified by their `shard_id`, which is a number ranging from `0` to `NUM_SHARDS-1`.`shard_id` is also used as part of the indexing keys by which trie nodes are stored in the database. -However, when shards may change accross epochs, `shard_id` can no longer be used to uniquely identify states because new shards and old shards will share the same `shard_id`s under this representation. +However, when shards may change across epochs, `shard_id` can no longer be used to uniquely identify states because new shards and old shards will share the same `shard_id`s under this representation. -To solve this issue, the new proposal creates a new struct `ShardUId` as an unique identifier to reference shards accross epochs. +To solve this issue, the new proposal creates a new struct `ShardUId` as an unique identifier to reference shards across epochs. `ShardUId` will only be used for storing and managing states, for example, in `Trie` related structures, In most other places in the code, it is clear which epoch the referenced shard belongs, and `ShardId` is enough to identify the shard. There will be no change in the protocol level since `ShardId` will continue to be used in protocol level specs. @@ -72,7 +72,7 @@ pub struct ShardUId { } ``` The version number is different between different shard layouts, to ensure `ShardUId`s for shards from different epochs are different. -`EpochManager` will be responsible for managing shard versions and `ShardUId` accross epochs. +`EpochManager` will be responsible for managing shard versions and `ShardUId` across epochs. ## Build New States Currently, when receiving the first block of every epoch, validators start downloading states to prepare for the next epoch. @@ -140,11 +140,11 @@ maps account id to shard id given a shard layout #### `ShardLayoutV0` ```rust pub struct ShardLayoutV0 { - /// map accounts evenly accross all shards + /// map accounts evenly across all shards num_shards: NumShards, } ``` -A shard layout that maps accounts evenly accross all shards -- by calculate the hash of account id and mod number of shards. This is added to capture the current `account_id_to_shard_id` algorithm, to keep backward compatibility for some existing tests. `parent_shards` for `ShardLayoutV1` is always `None` and `version`is always `0`. +A shard layout that maps accounts evenly across all shards -- by calculate the hash of account id and mod number of shards. This is added to capture the current `account_id_to_shard_id` algorithm, to keep backward compatibility for some existing tests. `parent_shards` for `ShardLayoutV1` is always `None` and `version`is always `0`. #### `ShardLayoutV1` ```rust @@ -189,7 +189,7 @@ pub fn for_protocol_version(&self, protocol_version: ProtocolVersion) -> &Arc Result<(ShardUId, CryptoHash), std::io::Error> @@ -353,7 +353,7 @@ However, the implementation of those approaches are overly complicated and does - What parts of the design do you expect to resolve through the implementation of this feature before stabilization? - There might be small changes in the detailed implementations or specifications of some of the functions described above, but the overall structure will not be changed. - What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP? - - One issue that is related to this NEP but will be resolved indepdently is how trie nodes are stored in the database. + - One issue that is related to this NEP but will be resolved independently is how trie nodes are stored in the database. Right now, it is a combination of `shard_id` and the node hash. Part of the change proposed in this NEP regarding `ShardId` is because of this. Plans on how to only store the node hash as keys are being discussed [here](https://github.com/near/nearcore/issues/4527), but it will happen after the Simple Nightshade migration since completely solving the issue will take some careful design and we want to prioritize launching Simple Nightshade for now. From 8df56f3f5cc16d620a90452a0ffe84baa4970206 Mon Sep 17 00:00:00 2001 From: King Date: Wed, 19 Feb 2025 11:21:17 +0100 Subject: [PATCH 4/6] Fix typos in specs/Standards/Tokens/MultiToken/Metadata.md --- specs/Standards/Tokens/MultiToken/Metadata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/Standards/Tokens/MultiToken/Metadata.md b/specs/Standards/Tokens/MultiToken/Metadata.md index 33668ba93..2c18848a1 100644 --- a/specs/Standards/Tokens/MultiToken/Metadata.md +++ b/specs/Standards/Tokens/MultiToken/Metadata.md @@ -33,7 +33,7 @@ Metadata applies at both the class level (`MTBaseTokenMetadata`) and the specifi type MTContractMetadata = { spec: string, // required, essentially a version like "mt-1.0.0" - name: string, // required Zoink's Digitial Sword Collection + name: string, // required Zoink's Digital Sword Collection } type MTBaseTokenMetadata = { From 5e7b661825b631f273e68739b1119ecfba78d1fc Mon Sep 17 00:00:00 2001 From: King Date: Wed, 19 Feb 2025 11:21:19 +0100 Subject: [PATCH 5/6] Fix typos in specs/Standards/Tokens/MultiToken/ApprovalManagement.md --- specs/Standards/Tokens/MultiToken/ApprovalManagement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/Standards/Tokens/MultiToken/ApprovalManagement.md b/specs/Standards/Tokens/MultiToken/ApprovalManagement.md index c80417ecf..2788a6849 100644 --- a/specs/Standards/Tokens/MultiToken/ApprovalManagement.md +++ b/specs/Standards/Tokens/MultiToken/ApprovalManagement.md @@ -209,7 +209,7 @@ Using near-cli: "token_ids": ["1"], }' --accountId alice --amount .000000000000000000000001 -Note that `market` will not get a cross-contract call in this case. The implementors of the Market app should implement [cron](https://en.wikipedia.org/wiki/Cron)-type functionality to intermittently check that Market still has the access they expect. +Note that `market` will not get a cross-contract call in this case. The implementers of the Market app should implement [cron](https://en.wikipedia.org/wiki/Cron)-type functionality to intermittently check that Market still has the access they expect. ### 7. Revoke all From 816c69ee62eab8f5685982bd5f3e40a28ffed50f Mon Sep 17 00:00:00 2001 From: King Date: Wed, 19 Feb 2025 11:21:20 +0100 Subject: [PATCH 6/6] Fix typos in specs/Standards/Tokens/MultiToken/Core.md --- specs/Standards/Tokens/MultiToken/Core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/Standards/Tokens/MultiToken/Core.md b/specs/Standards/Tokens/MultiToken/Core.md index 4d3bf3686..feea5aa4a 100644 --- a/specs/Standards/Tokens/MultiToken/Core.md +++ b/specs/Standards/Tokens/MultiToken/Core.md @@ -40,7 +40,7 @@ The issues with this in general is a problem with defining what metadata means a One of the areas that has broad sweeping implications from the [ERC-1155] standard is the lack of direct access to metadata. With Near's sharding we are able to have a [Metadata Extension](Metadata.md) for the standard that exists on chain. So developers and users are not required to use an indexer to understand, how to interact or interpret tokens, via token identifiers that they receive. -Another extension that we made was to provide an explicit ability for developers and users to group or link together series of NFTs/FTs or any combination of tokens. This provides additional flexiblity that the [ERC-1155] standard only has loose guidelines on. This was chosen to make it easy for consumers to understand the relationship between tokens within the contract. +Another extension that we made was to provide an explicit ability for developers and users to group or link together series of NFTs/FTs or any combination of tokens. This provides additional flexibility that the [ERC-1155] standard only has loose guidelines on. This was chosen to make it easy for consumers to understand the relationship between tokens within the contract. To recap, we choose to create this standard, to improve interoperability, developer ease of use, and to extend token representability beyond what was available directly in the FT or NFT standards. We believe this to be another tool in the developer's toolkit. It makes it possible to represent many types of tokens and to enable exchanges of many tokens within a single `transaction`.