From ea2875d632551f85fc380ee95cde93907c72a4c7 Mon Sep 17 00:00:00 2001 From: bogdan-rosianu Date: Wed, 19 Jun 2024 16:15:18 +0300 Subject: [PATCH 1/2] added redirects --- .../developer-reference/sc-annotations.md | 4 +- .../developer-reference/sc-api-functions.md | 2 +- .../user-defined-smart-contracts.md | 4 +- docs/developers/overview.md | 4 +- docs/developers/smart-contracts.md | 2 +- .../testing/rust/sc-test-overview.md | 4 +- docs/learn/architecture-overview.md | 4 +- docusaurus.config.js | 44 +++++++++++++++++++ 8 files changed, 56 insertions(+), 12 deletions(-) diff --git a/docs/developers/developer-reference/sc-annotations.md b/docs/developers/developer-reference/sc-annotations.md index 5f8a9e9c6..361200497 100644 --- a/docs/developers/developer-reference/sc-annotations.md +++ b/docs/developers/developer-reference/sc-annotations.md @@ -45,7 +45,7 @@ Only one contract, module or proxy annotation is allowed per Rust module. If the ### `#[multiversx_sc::proxy]` -The `proxy` annotation must always be placed on a trait and will automatically make that trait a smart contract call proxy. More about smart contract proxies in [the contract calls reference](/developers/developer-reference/sc-contract-calls). +The `proxy` annotation must always be placed on a trait and will automatically make that trait a smart contract call proxy. More about smart contract proxies in [the contract calls reference](/developers/transactions/tx-legacy-calls). In short, contracts always get an auto-generated proxy. However, if such an auto-generated proxy of another contract is not available, it is possible to define such a "contract interface" by hand, using the `proxy` attribute. @@ -129,7 +129,7 @@ Callbacks are special methods that get called automatically when the response co They also act as closures, since they can retain some of the context of the transaction that performed the asynchronous call in the first place. -A more detailed explanation on how they work in [the contract calls reference](/developers/developer-reference/sc-contract-calls). +A more detailed explanation on how they work in [the contract calls reference](/developers/transactions/tx-legacy-calls). [comment]: # (mx-context-auto) diff --git a/docs/developers/developer-reference/sc-api-functions.md b/docs/developers/developer-reference/sc-api-functions.md index 9d1273bc1..7be2f486a 100644 --- a/docs/developers/developer-reference/sc-api-functions.md +++ b/docs/developers/developer-reference/sc-api-functions.md @@ -523,7 +523,7 @@ This API is accessible through `self.send()`. It provides functionalities like s We will not describe every single function in the API, as that would create confusion. We will only describe those that are recommended to be used (as they're mostly wrappers around more complicated low-level functions). -For Smart Contract to Smart Contract calls, use the Proxies, as described in the [contract calls](sc-contract-calls.md) section. +For Smart Contract to Smart Contract calls, use the Proxies, as described in the [contract calls](/developers/transactions/tx-legacy-calls) section. Without further ado, let's take a look at the available functions: diff --git a/docs/developers/gas-and-fees/user-defined-smart-contracts.md b/docs/developers/gas-and-fees/user-defined-smart-contracts.md index 608545279..0e8988072 100644 --- a/docs/developers/gas-and-fees/user-defined-smart-contracts.md +++ b/docs/developers/gas-and-fees/user-defined-smart-contracts.md @@ -132,8 +132,8 @@ Documentation in this section is preliminary and subject to change. Furthermore, Before moving forward, make sure you first have a look over the following: -- [Asynchronous calls between contracts](/technology/the-wasm-vm/#asynchronous-calls-between-contracts) -- [Asynchronous calls (Rust framework)](/developers/developer-reference/sc-contract-calls/#asynchronous-calls) +- [Asynchronous calls between contracts](/learn/space-vm#asynchronous-calls-between-contracts) +- [Asynchronous calls (Rust framework)](/developers/transactions/tx-legacy-calls#asynchronous-calls) - [Callbacks (Rust framework)](/developers/developer-reference/sc-annotations/#callbacks) Suppose we have two contracts: `A` and `B`, where `A::foo(addressOfB)` asynchronously calls `B::bar()` (e.g. using `asyncCall()`). diff --git a/docs/developers/overview.md b/docs/developers/overview.md index 3ff1388d7..ec57319a6 100644 --- a/docs/developers/overview.md +++ b/docs/developers/overview.md @@ -90,7 +90,7 @@ Learn about transaction's gas and how a fee is calculated: | [MultiversX serialization format](/developers/data/serialization-overview) | How MultiversX smart contracts serialize arguments, results, and storage. | | [MultiversX SC annotations](/developers/developer-reference/sc-annotations) | How to use annotations in your contracts to make use of many built-in features from the framework. | | [MultiversX SC modules](/developers/developer-reference/sc-modules) | Learn how to divide a Smart Contract into multiples smaller components by using modules. | -| [MultiversX SC contract calls](/developers/developer-reference/sc-contract-calls) | Learn how to call a Smart Contract from another Smart Contract. | +| [MultiversX SC contract calls](/developers/transactions/tx-legacy-calls) | Learn how to call a Smart Contract from another Smart Contract. | | [Code metadata](/developers/data/code-metadata) | Choose the properties / eligible actions of your Smart Contract. | | [Upgrading smart contracts](/developers/developer-reference/upgrading-smart-contracts) | The implications of upgrading a Smart Contract. | | [MultiversX SC api functions](/developers/developer-reference/sc-api-functions) | Make use of the MultiversX VM API functions to query relevant data from the blockchain. | @@ -117,7 +117,7 @@ Learn about transaction's gas and how a fee is calculated: | Name | Description | |----------------------------------------------------------------------|----------------------------------------------------------| | [Overview](/developers/testing/rust/sc-test-overview) | Introduction to all the testing methods available in Rust| -| [Blackbox tests](/developers/testing/rust/sc-blackbox) | The best way to write integration tests, by simulating transactionds| +| [Blackbox tests](/developers/testing/rust/sc-blackbox-calls) | The best way to write integration tests, by simulating transactionds| | [Whitebox framework](/developers/testing/rust/whitebox-legacy) | Older testing framework, but still in use in some projects.| | [Whitebox framework functions reference](/developers/testing/rust/whitebox-legacy-functions-reference) | A list of available functions to be used when using the whitebox framework. | | [Debugging](/developers/testing/sc-debugging) | How to debug your smart contract tests. | diff --git a/docs/developers/smart-contracts.md b/docs/developers/smart-contracts.md index 5f657ebd9..36d779724 100644 --- a/docs/developers/smart-contracts.md +++ b/docs/developers/smart-contracts.md @@ -15,6 +15,6 @@ which allows for unusually clean and efficient code in smart contracts, a rarity A declarative testing framework is bundled as well. For the best coding experience, developers have the [MultiversX IDE](https://marketplace.visualstudio.com/items?itemName=Elrond.vscode-elrond-ide) at their disposal. -Read more about the MultiversX VM [here](/technology/the-wasm-vm). +Read more about the MultiversX VM [here](/learn/space-vm). Navigate through the sidebar to see some tutorials to get you started, as well as the Rust framework documentation. diff --git a/docs/developers/testing/rust/sc-test-overview.md b/docs/developers/testing/rust/sc-test-overview.md index dfdc38eee..b32a70587 100644 --- a/docs/developers/testing/rust/sc-test-overview.md +++ b/docs/developers/testing/rust/sc-test-overview.md @@ -45,11 +45,11 @@ Since this operation is specific to only the Rust debugger, it doesn't go throug ### Calling contract code -There are many ways to call contract code, but the one we recommend is [black-box style](sc-blackbox) using the [unified transaction syntax](/developers/transactions/tx-overview). +There are many ways to call contract code, but the one we recommend is [black-box style](/developers/testing/rust/sc-blackbox-calls) using the [unified transaction syntax](/developers/transactions/tx-overview). The call styles are: - unified transaction syntax - - [**black-box**](sc-blackbox) (recommended) + - [**black-box**](/developers/testing/rust/sc-blackbox-calls) (recommended) - white-box (coming soon) - Mandos steps in Rust (no longer recommended) - [Whitebox framework (legacy)](whitebox-legacy) diff --git a/docs/learn/architecture-overview.md b/docs/learn/architecture-overview.md index fa2fb76e1..6c89dcbe2 100644 --- a/docs/learn/architecture-overview.md +++ b/docs/learn/architecture-overview.md @@ -7,10 +7,10 @@ MultiversX is a high-throughput public blockchain aimed at providing security, e MultiversX is a complete redesign of blockchain architecture with the aim to achieve global scalability and near instant transaction speed. MultiversX's architecture rests on the following key innovations: -1. [**Adaptive State Sharding**](adaptive-state-sharding.md) on all levels: transaction, data and network. The dynamically adaptive sharding mechanism will perform shard merging and shard splitting while taking into consideration both the number of available validator nodes and also the network usage. +1. [**Adaptive State Sharding**](consensus.md) on all levels: transaction, data and network. The dynamically adaptive sharding mechanism will perform shard merging and shard splitting while taking into consideration both the number of available validator nodes and also the network usage. 2. [**Secure Proof of Stake**](/technology/secure-proof-of-stake) **Consensus**, completed in just two communication steps, using modified Boneh–Lynn–Shacham ("BLS") multi-signatures among the validators of the consensus group. Moreover, nodes inside the shard are randomly selected for the consensus group with no possibility of knowing the group's composition more than one round in advance. 3. **High resiliency** to malicious attacks due to periodical node reshuffling across shards. Every epoch, up to 1/3 of the nodes in every shard are reshuffled to other shards in order to prevent collusion. 4. **Secure randomness source** with BLS signing, which makes it non-biasable and unpredictable. -5. The [**MultiversX WASM VM**](/technology/the-wasm-vm), an exceptionally fast virtual machine for executing smart contracts written in _any programming language_ that can compile to WebAssembly. +5. The [**MultiversX WASM VM**](/learn/space-vm), an exceptionally fast virtual machine for executing smart contracts written in _any programming language_ that can compile to WebAssembly. 6. **Smart contracts on a sharded state architecture**, with balanced load on shards. This is a requirement for a high-throughput blockchain platform. Balancing smart contracts across shards allows MultiversX to run multiple SCs in parallel, while the cross-shard calls are handled by an asynchronous [cross-shard execution process](/technology/cross-shard-transactions). 7. **Fast finality for cross-shard transactions** in mere seconds. Having a very high TPS is required for a high throughput blockchain solution, but TPS is only half the picture: fast finality for cross-shard transactions is of crucial importance. Most existing state-of-the-art blockchain architectures refuse to mention this aspect, but from a user standpoint it is extremely important. Fast cross-shard finality is naturally handled by MultiversX at the protocol level, using a dispatching algorithm and a routing protocol. diff --git a/docusaurus.config.js b/docusaurus.config.js index b249f1090..7836b929f 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -199,6 +199,50 @@ const config = { "@docusaurus/plugin-client-redirects", { redirects: [ + { + from: "/technology/glossary", + to: "/welcome/terminology", + }, + { + from: "/technology/architecture-overview", + to: "/learn/architecture-overview", + }, + { + from: "/technology/secure-proof-of-stake", + to: "/learn/consensus", + }, + { + from: "/technology/chronology", + to: "/learn/chronology", + }, + { + from: "/technology/entities", + to: "/learn/entities", + }, + { + from: "/technology/adaptive-state-sharding", + to: "/learn/sharding", + }, + { + from: "/technology/cross-shard-transactions", + to: "/learn/transactions", + }, + { + from: "/economics", + to: "/learn/economics", + }, + { + from: "/tokens/esdt-tokens", + to: "/tokens/fungible-tokens", + }, + { + from: "/tokens/overview", + to: "/tokens/intro", + }, + { + from: "/validators/staking/convert-existing-validator-into-staking-pool", + to: "/validators/staking/convert-existing-validator-into-staking-provider", + }, { from: "/sdk-and-tools/rest-api/api-com/", to: "/sdk-and-tools/rest-api/multiversx-api/", From 7883dc6e1d3e504f8f75bee35278ef93e7681fef Mon Sep 17 00:00:00 2001 From: bogdan-rosianu Date: Wed, 19 Jun 2024 16:25:19 +0300 Subject: [PATCH 2/2] further fixes --- src/components/HomepageFeatures/index.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/components/HomepageFeatures/index.js b/src/components/HomepageFeatures/index.js index e0a489238..730dca044 100644 --- a/src/components/HomepageFeatures/index.js +++ b/src/components/HomepageFeatures/index.js @@ -40,14 +40,14 @@ const FeatureList = [ title: "Create a Token", content: "Issue your own ESDT token, MultiversX's improved equivalent of ERC-20.", - docName: "tokens/overview", + docName: "tokens/intro", icon: "🔷", }, { title: "Learn How MultiversX Works", content: "Explore Adaptive state sharding, Secure Proof of Stake, and the MultiversX WASM VM.", - docName: "technology/architecture-overview", + docName: "learn/architecture-overview", icon: "🔬", }, ];