Fixes for rust sdk

docs/1.concepts/protocol/access-keys.md

@@ -11,6 +11,9 @@ NEAR accounts present the **unique** feature of being able to hold multiple [Acc
 1. `Full-Access Keys`: Have full control over the account, and should **never be shared**
 2. `Function-Call Keys`: Can sign calls to specific contract, and are **meant to be shared**
 
+
+Currently supported curve types are `ed25519` (default curve type used for public key cryptography in NEAR) and `secp256k1` (supported for compatibility with other blockchains).
+
 ---
 
 ## Full-Access Keys {#full-access-keys}

docs/1.concepts/protocol/gas.md

@@ -100,7 +100,7 @@ The cost of calling a function will depend on how complex the function is, but w
 :::
 
 :::tip Deploying a Contract**
-Note that this covers the gas cost of uploading and writing bytes to storage, but does **not** cover the cost of holding them in storage (which is `1Ⓝ ~ 100kb`).
+Note that this covers the gas cost of uploading and writing bytes to storage, but does **not** cover the cost of holding them in storage (which is `1Ⓝ ~ 100kb`). More information about storage staking [here](../storage/storage-staking.md)
 :::
 
 <details className="info">

docs/2.build/2.smart-contracts/anatomy/collections.md

@@ -109,8 +109,8 @@ SDK collections are useful when you are planning to store large amounts of data
 |-----------------------------------------------|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `store::Vector<T>`                            | `Vec<T>`                          | A growable array type. The values are sharded in memory and can be used for iterable and indexable values that are dynamically sized.                                                             |
 | <code>store::LookupMap`<K,&nbsp;V>`</code>    | <code>HashMap`<K,&nbsp;V>`</code> | This structure behaves as a thin wrapper around the key-value storage available to contracts. This structure does not contain any metadata about the elements in the map, so it is not iterable.  |
-| <code>store::IterableMap`<K,&nbsp;V>`</code>  | <code>HashMap`<K,&nbsp;V>`</code> | Similar to `LookupMap`, except that it stores additional data to be able to iterate through elements in the data structure.                                                                       |
-| <code>store::UnorderedMap`<K,&nbsp;V>`</code> | <code>HashMap`<K,&nbsp;V>`</code> | Similar to `LookupMap`, except that it stores additional data to be able to iterate through elements in the data structure.                                                                       |
+| <code>store::IterableMap`<K,&nbsp;V>`</code>  | <code>HashMap`<K,&nbsp;V>`</code> | Similar to `LookupMap`, except that it stores additional data to be able to iterate through elements in the data structure. To be used when remove is not a frequent operation.                                                                       |
+| <code>store::UnorderedMap`<K,&nbsp;V>`</code> | <code>HashMap`<K,&nbsp;V>`</code> | Similar to `LookupMap`, except that it stores additional data to be able to iterate through elements in the data structure. Optimized for fast removal. Other operations become slower.                                                                       |
 | `store::LookupSet<T>`                         | `HashSet<T>`                      | A set, which is similar to `LookupMap` but without storing values, can be used for checking the unique existence of values. This structure is not iterable and can only be used for lookups.      |
 | `store::IterableSet<T>`                       | `HashSet<T>`                      | An iterable equivalent of `LookupSet` which stores additional metadata for the elements contained in the set.                                                                                     |
 | `store::UnorderedSet<T>`                      | `HashSet<T>`                      | An iterable equivalent of `LookupSet` which stores additional metadata for the elements contained in the set.                                                                                     |

docs/2.build/2.smart-contracts/anatomy/crosscontract.md

@@ -41,7 +41,16 @@ While making your contract, it is likely that you will want to query information
     <Github fname="lib.rs"
             url="https://github.com/near-examples/cross-contract-calls/blob/main/contract-simple-rs/src/lib.rs"
             start="22" end="51" />
-            <Github fname="external.rs"
+
+</Language>
+
+</CodeTabs>
+
+Note that in order for that to work in Rust, you have to implement the interface of the contract you call:
+
+<CodeTabs>
+<Language value="rust" language="rust">
+        <Github fname="external.rs"
             url="https://github.com/near-examples/cross-contract-calls/blob/main/contract-simple-rs/src/external.rs"
             start="2" end="12" />
 
@@ -66,6 +75,13 @@ Calling another contract passing information is also a common scenario. Below yo
     <Github fname="lib.rs"
             url="https://github.com/near-examples/cross-contract-calls/blob/main/contract-simple-rs/src/lib.rs"
             start="53" end="80" />
+
+</Language>
+
+</CodeTabs>
+
+<CodeTabs>
+<Language value="rust" language="rust">
     <Github fname="external.rs"
             url="https://github.com/near-examples/cross-contract-calls/blob/main/contract-simple-rs/src/external.rs"
             start="2" end="12" />
@@ -149,10 +165,34 @@ You can attach an unused GAS weight by specifying the `.with_unused_gas_weight()
   </TabItem>
 </Tabs>
 
-:::info
+:::caution
 
 If a function returns a promise, then it will delegate the return value and status of transaction execution, but if you return a value or nothing, then the `Promise` result will not influence the transaction status
 
+
+
+Unless there is a very good reason not to, all the cross-contract calling functions should return the Promise as the result of its execution, otherwise, the cross-contract calls won't affect the result of the contract execution.
+
+For example:
+<Tabs>
+  <TabItem value="rs" label="🦀 Rust">
+
+    ```rust
+    fn destroy(&mut self) {
+        Promise::...; // notice the `;` here and the empty return value in the function signature
+    }
+    fn destroy(&mut self) -> Promise {
+        Promise::... // notice there is no `;` here and the return value in the function signature Promise
+    }
+    ```
+
+  </TabItem>
+</Tabs>
+
+The difference between the two is that the first will schedule the cross-contract call, but its return value will be ignored (even if the call fails, the result of the `destroy` function will be OK), and transaction return value may even be returned earlier than all the in-flight cross-contract calls complete since they do not affect the execution result.
+
+Without linking the cross-contract call with the result of the `destroy` function, it may start removing itself earlier than the cross-contract call is finished and if it fails, it's state will become unreachable.
+
 :::
 
 :::caution